multithread with egcs/(C++) and RedHat 5.0

multithread with egcs/(C++) and RedHat 5.0

[Torbjörn Eriksson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

Hello,

First of all, I apologize if this question shouldn't bee here at all.
I'm quite new at programming threads, so I don't really know if this
problem is related to egcs at all.

Background: We're 4 students working on a project at University of
Karlskrona-Ronneby i southern Sweden. We decided to develop our project
in C++ on a Linux box, (RedHat 5.0). After doing some research we found
out that gcc ver. 2.7.2 doesn't work with threads, and that egcs would.

Our problem is that system calls like readdir_r and localtime_r causes
segmention faults, this is a printout from gdb.

#0  0x4004c93c in __pthread_mutex_lock () at mutex.c:135
#1  0x4004e28c in __fresetlockfiles () at lockfile.c:87
#2  0x400a7053 in _IO_fread (buf=0xbffff7a0, size=44, count=1,
fp=0x804e250)
    at iofread.c:44
#3  0x400c546e in __tzfile_compute (timer=1074773704,
    use_localtime=1074807804, leap_correct=0xbffff860,
leap_hit=0xbffff8cc)
    at tzfile.c:283
#4  0x400c4413 in tzset_internal () at tzset.c:197
#5  0x400c518c in __tz_convert () at tzset.c:561
#6  0x400c1c2f in localtime (t=0xbffff8cc) at localtime.c:49
#7  0x8048f1c in ThreadClass::Notify () at ThreadClass.cc:103
#8  0x8048e48 in ThreadClass::ScanDir (this=0x804c1d0) at
ThreadClass.cc:66
#9  0x8048daa in ThreadClass::Listen (this=0x804c1d0) at
ThreadClass.cc:44
#10 0x8048bfe in main () at main.cc:23

I do'nt know, but I suspect that we might start the thread in an illegal
way

pthread_t
ThreadClass::Run()
{
  pthread_attr_init(&myThreadAttr);
  pthread_attr_setscope(&myThreadAttr, PTHREAD_SCOPE_SYSTEM);

  if (pthread_create(&myThread, &myThreadAttr, SpawnThread, this)==0)
    {
      return myThread;
    }else
      return (0);
}

// this one is declared as static void* in ThreadClass.hh
//  ThreadClass::Listen is a ordinary member function returning void*

void*
ThreadClass::SpawnThread(void* arg)
{
  return (((ThreadClass *) arg)->Listen());
}

Listen memberfunction just sleeps for a while and then it calls ScanDir
that does a readdir_r on a directory, when a file is found it calls
Notify with the filename

void
ThreadClass::Notify(char* filename)
{
  struct stat sbuf;
  struct tm   tptr;

  if (!lstat(filename, &sbuf))
    {
      localtime_r(&(sbuf.st_mtime), &tptr);
    }
}

In localtime_r, the program causes a segm. fault

We have installed
gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)
and the prerequisits that the rpm asked for.

We will be very grateful for any help or suggestions, and, once again,
I'm sorry if  this question doesn't belong here, but after browsing
through this mail archive and searching the net, it seemed to be a good
place to start.

Thorbjörn Eriksson
pt96ter@student.hk-r.se
pt96ter@palantir.proj.ide.hk-r.se

Re: multithread with egcs/(C++) and RedHat 5.0

[Jeffrey A Law]

  In message < ylfjn2daasyx.fsf@law.miami.edu >you write:
  > > What version of egcs is Debian using in their package?
  > 
  > I believe the c++ package for i386 is based on 1.0.2.  I _know_ the
  > alpha package is.
If it's 1.0.x based, then it will not have thread-safe exceptions.

jeff

Re: multithread with egcs/(C++) and RedHat 5.0

[Michael Alan Dorman]

Jeffrey A Law <law@cygnus.com> writes:
>   In message < Pine.GSO.3.95.980424083005.9333B-100000@vuokko >you write:
>   > > If you want threads to throw exceptions, you have to use a
>   > > developmental EGCS snapshot rather than a released version,
>   > > and go through some magic incantations to build the
>   > > thread-safe exception handling.
>   > 
>   > Really? I have only read that thread-safe exception handling is
>   > implemented and I assumed that it is compiled in by default. Anyone know,
>   > whether the debian egcs (g++) package includes thread-safe exception
>   > handling?
> What version of egcs is Debian using in their package?

I believe the c++ package for i386 is based on 1.0.2.  I _know_ the
alpha package is.

Mike.

Re: multithread with egcs/(C++) and RedHat 5.0

[Jeffrey A Law]

  In message < Pine.GSO.3.95.980424083005.9333B-100000@vuokko >you write:
  > > If you want threads to throw exceptions, you have to use a
  > > developmental EGCS snapshot rather than a released version,
  > > and go through some magic incantations to build the
  > > thread-safe exception handling.
  > 
  > Really? I have only read that thread-safe exception handling is
  > implemented and I assumed that it is compiled in by default. Anyone know,
  > whether the debian egcs (g++) package includes thread-safe exception
  > handling?
What version of egcs is Debian using in their package?

jeff

RE: multithread with egcs/(C++) and RedHat 5.0

[Niku Kaitaniemi]

> If you want threads to throw exceptions, you have to use a
> developmental EGCS snapshot rather than a released version,
> and go through some magic incantations to build the
> thread-safe exception handling.

Really? I have only read that thread-safe exception handling is
implemented and I assumed that it is compiled in by default. Anyone know,
whether the debian egcs (g++) package includes thread-safe exception
handling?

--
"This code is guaranteed."  - Famous last words
niksa@uta.fi

Re: multithread with egcs/(C++) and RedHat 5.0

[Torbjörn Eriksson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

On Wed, 22 Apr 1998, B. James Phillippe wrote:

> On Wed, 22 Apr 1998, Torbjörn Eriksson wrote:
> 
> > Hello,
> > 
> > First of all, I apologize if this question shouldn't bee here at all.
> > I'm quite new at programming threads, so I don't really know if this
> > problem is related to egcs at all.
> 
> Hello.  I too am a beginning pthreads programmer.  I'm not sure I can help
> you, but I do have two questions for you.  See below..
> 
> > Our problem is that system calls like readdir_r and localtime_r causes
> > segmention faults, this is a printout from gdb.
> 
> I was under the impression that we should not use explicit _r variants
> (such as localtime_r); instead to compile with -D_REENTRANT would
> automatically use the reentrant versions.

Actually, we use -D_REENTRANT too, 

> 
> >   if (pthread_create(&myThread, &myThreadAttr, SpawnThread, this)==0)
> ...
> > // this one is declared as static void* in ThreadClass.hh
> > //  ThreadClass::Listen is a ordinary member function returning void*
> > 
> > void*
> > ThreadClass::SpawnThread(void* arg)
> > {
> >   return (((ThreadClass *) arg)->Listen());
> > }
> 
> This looks like you are trying to initialize a pthread with a pointer to
> member function (being cast to a void*).  I believe this is not allowed,
> because a pointer to member function is actually an offset into an object,
> and not simply the absolute address of a function.  Also, in section 5.6 of
> Stroustrup's 3rd ed. "C++ Programming Language" there is specific statement
> that pointer to function and pointer to member can not be assigned to
> void*.

The Spawnthread function is a memberfunction but it's declared as static
void * in the class ThreadClass. I have also tried to get it to work by
creating a non member function, static void *, that was called by
pthread_create. This function then created the object of type ThreadClass
and run its memberfunction obj->Listen().  

 > 
> Again, I am a threads novice so I may be mistaken.

As I said in my first mail, we appreciate any effort to help us get our
project running ;-)
  
> But that is the
> understanding that I have been programming with, using pthreads and C++ on
> a RedHat 5.0 glibc system.
> 
> Hope this helps,
> -bp
> --
> B. James Phillippe <bryan@terran.org>
> Linux Software Engineer, WGT Inc.
> http://earth.terran.org/~bryan
> 
> 

RE: multithread with egcs/(C++) and RedHat 5.0

[Torbjörn Eriksson]

On Wed, 22 Apr 1998, Kaz Kylheku wrote:

> On Wednesday, April 22, 1998 5:30 AM, Torbjvrn Eriksson 
> [SMTP:pt96ter@palantir.proj.ide.hk-r.se] wrote:
> > Hello,
> >
> >
> > Our problem is that system calls like readdir_r and localtime_r causes
> > segmention faults, this is a printout from gdb.
> 
> Read the LinuxThreads FAQ! You can't use GDB on multi-threaded
> programs; it doesn't recongize threads. At best, you can trace the
> main thread. (If any other thread hits a breakpoint set in the main
> thread, your program will crash). Core files are also of little
> value.
> 
> > #0  0x4004c93c in __pthread_mutex_lock () at mutex.c:135
> > #1  0x4004e28c in __fresetlockfiles () at lockfile.c:87
> > #2  0x400a7053 in _IO_fread (buf=0xbffff7a0, size=44, count=1,
> > fp=0x804e250)
> >     at iofread.c:44
> > #3  0x400c546e in __tzfile_compute (timer=1074773704,
> >     use_localtime=1074807804, leap_correct=0xbffff860,
> > leap_hit=0xbffff8cc)
> >     at tzfile.c:283
> > #4  0x400c4413 in tzset_internal () at tzset.c:197
> > #5  0x400c518c in __tz_convert () at tzset.c:561
> > #6  0x400c1c2f in localtime (t=0xbffff8cc) at localtime.c:49
> > #7  0x8048f1c in ThreadClass::Notify () at ThreadClass.cc:103
> > #8  0x8048e48 in ThreadClass::ScanDir (this=0x804c1d0) at
> > ThreadClass.cc:66
> > #9  0x8048daa in ThreadClass::Listen (this=0x804c1d0) at
> > ThreadClass.cc:44
> > #10 0x8048bfe in main () at main.cc:23
> 
> See, this trace doesn't tell me anything! It just looks like your
> main thread went into a bunch of nested function calls and
> finally hit a mutex lock, and stuck there.
>
Sorry, I left out some info there. This printout was made without actually
starting the thread. When it didnt work with the thread I modified the
testprogram to call the Listen member func. from the main thread and to
not start the thread that should do this at all. Even then it ended up in
a segm. fault in pthread_mutex_lock.


 > The actual program crash might have easily been caused by
> another thread in some part of the code that you can only
> guess at.
> 
> Your only hope is to insert diagnostic statements everywhere
> and read the resulting log.
> 
> I have written a class that can be used for diagnosing multi-threaded
> Linux programs; it will write the diagnostics of each thread into
> a separate file, with time stamps and sequence numbers so
> that you can trace the scenario of a failure across multiple
> threads.

would you like to share it with us ?

> 
> > I do'nt know, but I suspect that we might start the thread in an illegal
> > way
> >
> > pthread_t
> > ThreadClass::Run()
> > {
> >   pthread_attr_init(&myThreadAttr);
> >   pthread_attr_setscope(&myThreadAttr, PTHREAD_SCOPE_SYSTEM);
> >
> >   if (pthread_create(&myThread, &myThreadAttr, SpawnThread, this)==0)
> 
> Holy cow, I hope you declared SpawnThread as a static member function.

Yes, its declared as static void* in the class ThreadClass

> You can't specify an ordinary member function
> as the thread entry point! Member functions are not like ordinary C functions.
> They can only be used in conjunction with an object.
> 
> You can use a static member function as your thread stub, but to be
> absolutely correct, you should use a non-member function declared
> extern "C".
> 
> > In localtime_r, the program causes a segm. fault
> >
> > We have installed
> > gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)
> > and the prerequisits that the rpm asked for.
> 
> Are you using exception handling? 
No

> Which libc are you using?

glibc 2.0.7

> 
> If you want threads to throw exceptions, you have to use a
> developmental EGCS snapshot rather than a released version,
> and go through some magic incantations to build the
> thread-safe exception handling.

I think I would be quite happy without worrying about execption too ;-)

RE: multithread with egcs/(C++) and RedHat 5.0

[Kaz Kylheku]

On Wednesday, April 22, 1998 5:30 AM, Torbjvrn Eriksson 
[SMTP:pt96ter@palantir.proj.ide.hk-r.se] wrote:
> Hello,
>
> First of all, I apologize if this question shouldn't bee here at all.
> I'm quite new at programming threads, so I don't really know if this
> problem is related to egcs at all.
>
> Background: We're 4 students working on a project at University of
> Karlskrona-Ronneby i southern Sweden. We decided to develop our project
> in C++ on a Linux box, (RedHat 5.0). After doing some research we found
> out that gcc ver. 2.7.2 doesn't work with threads, and that egcs would.
>
> Our problem is that system calls like readdir_r and localtime_r causes
> segmention faults, this is a printout from gdb.

Read the LinuxThreads FAQ! You can't use GDB on multi-threaded
programs; it doesn't recongize threads. At best, you can trace the
main thread. (If any other thread hits a breakpoint set in the main
thread, your program will crash). Core files are also of little
value.

> #0  0x4004c93c in __pthread_mutex_lock () at mutex.c:135
> #1  0x4004e28c in __fresetlockfiles () at lockfile.c:87
> #2  0x400a7053 in _IO_fread (buf=0xbffff7a0, size=44, count=1,
> fp=0x804e250)
>     at iofread.c:44
> #3  0x400c546e in __tzfile_compute (timer=1074773704,
>     use_localtime=1074807804, leap_correct=0xbffff860,
> leap_hit=0xbffff8cc)
>     at tzfile.c:283
> #4  0x400c4413 in tzset_internal () at tzset.c:197
> #5  0x400c518c in __tz_convert () at tzset.c:561
> #6  0x400c1c2f in localtime (t=0xbffff8cc) at localtime.c:49
> #7  0x8048f1c in ThreadClass::Notify () at ThreadClass.cc:103
> #8  0x8048e48 in ThreadClass::ScanDir (this=0x804c1d0) at
> ThreadClass.cc:66
> #9  0x8048daa in ThreadClass::Listen (this=0x804c1d0) at
> ThreadClass.cc:44
> #10 0x8048bfe in main () at main.cc:23

See, this trace doesn't tell me anything! It just looks like your
main thread went into a bunch of nested function calls and
finally hit a mutex lock, and stuck there.

The actual program crash might have easily been caused by
another thread in some part of the code that you can only
guess at.

Your only hope is to insert diagnostic statements everywhere
and read the resulting log.

I have written a class that can be used for diagnosing multi-threaded
Linux programs; it will write the diagnostics of each thread into
a separate file, with time stamps and sequence numbers so
that you can trace the scenario of a failure across multiple
threads.

> I do'nt know, but I suspect that we might start the thread in an illegal
> way
>
> pthread_t
> ThreadClass::Run()
> {
>   pthread_attr_init(&myThreadAttr);
>   pthread_attr_setscope(&myThreadAttr, PTHREAD_SCOPE_SYSTEM);
>
>   if (pthread_create(&myThread, &myThreadAttr, SpawnThread, this)==0)

Holy cow, I hope you declared SpawnThread as a static member function.
You can't specify an ordinary member function
as the thread entry point! Member functions are not like ordinary C functions.
They can only be used in conjunction with an object.

You can use a static member function as your thread stub, but to be
absolutely correct, you should use a non-member function declared
extern "C".

> In localtime_r, the program causes a segm. fault
>
> We have installed
> gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)
> and the prerequisits that the rpm asked for.

Are you using exception handling? Which libc are you using?
For threaded programming you should use glibc2, which incorporates
LinuxThreads. You can also get away with libc5, as long as you
have properly installed Linuxthreads 0.7x over top of it.

If you want threads to throw exceptions, you have to use a
developmental EGCS snapshot rather than a released version,
and go through some magic incantations to build the
thread-safe exception handling.