[linux-audio-dev] pthreads and signals

Paul Davis paul at linuxaudiosystems.com
Wed May 14 13:03:00 UTC 2003

>According to the O'Reilly] Pthreads (Caterpillar) book, signals due to
>system exceptions (like SIGFPE, or SIGSEGV) are "synchronous" and
>*must* be delivered to the offending thread.  Quoting...
>  "It will be that thread, in its own context, that will handle the
>  signal on behalf of the process as a whole."

thats a very useful thing to know. its not mentioned in the book i use
on threads (kleiman/shah/smaalders). they mention the sync/async
distinction, but not the requirement that they be handled by the
thread that caused them.

i wonder if the kernel is enforcing the sync rule? i don't see how it
could, though - it doesn't know about linuxthreads. we've blocked
SIGSEGV, yet the thread still receives it. strange. maybe you can't
block SIGSEGV? why wouldn't sigaction fail?

>I suspect something strange here.  I've seen crashes where the JACK
>thread has disappeared before the core dump was written.  Could they
>have been triggered by a segfault in the process() thread?  

unless the kernel has been fixed since i last checked on this (and i
have a vague memory that it has been), linux doesn't write core files
for multi-threaded processes.

>No, but I'm interested.  Right now, I'd be happy just to reliably get
>a dump with the backtrace stack of the offending thread intact.
>Sometimes that happens, other times not.

i'll try to fix JACK so that it does the same thing as ardour is doing
now (exiting from within the handler).


More information about the Linux-audio-dev mailing list