2.4.4: thread dumping core
Hi,
I wonder whether the kernel does the right thing if a thread causes a segmentation violation: Currently it seems the other LWPs just continue. However in practice this means that the application does not work reliable when one thread went away.
I suggest to terminate all LWPs if one receives a fatal signal.
I wasn't successful debugging the beast:
Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpthread.so.0...done. rw_common (): write: Success.
warning: unable to set global thread event mask [New Thread 1024 (LWP 10566)]
Error while reading shared library symbols:attach_thread: No such process.
Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2
#0 0x4005e0a6 in sigsuspend () from /lib/libc.so.6 (gdb) bt
#0 0x4005e0a6 in sigsuspend () from /lib/libc.so.6 #1 0x4002496c in sigwait () from /lib/libpthread.so.0 #2 0x804da47 in mi_signal_thread () #3 0x40021ba3 in pthread_start_thread () from /lib/libpthread.so.0
Opinions?
Ulrich
Quoted 3 lines
I wonder whether the kernel does the right thing if a thread causes a segmentation violation: Currently it seems the other LWPs just continue. However in practice this means that the application does not
This is a feature in most cases
Quoted 1 line
I suggest to terminate all LWPs if one receives a fatal signal.
So write some signal handlers.
In all cases the other threads will continue for some time, so you gain nothing by pretending they dont.
Alan
Quoted 9 lines · Alan Cox
Quoted 3 lines
I wonder whether the kernel does the right thing if a thread causes a segmentation violation: Currently it seems the other LWPs just continue. However in practice this means that the application does not
This is a feature in most cases
Quoted 1 line
I suggest to terminate all LWPs if one receives a fatal signal.
So write some signal handlers.
Actually I'm using a wrapper library that is supposed to do that stuff for me (libmilter from sendmail-8.12.0.Beta16).
Quoted 3 lines
In all cases the other threads will continue for some time, so you gain nothing by pretending they dont.
Imagine you aquire a lock in one thread then that thread gets a SIGSEGV. There are a lot of threads around, possibly consuming a lot of CPU without getting any (a lot of) work done.
Maybe the real problem is a simple a a binary incompatibility between libpthread form SuSE 7.1 and SuSE 7.2 (which would be a very bad case). As for any real bug, the application works most of the time.
Thanks for the statement.
Ulrich