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 ;-)