Subject: Re: [linux-audio-dev] pthreads and signals
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Wed May 14 2003 - 19:54:00 EEST
>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).
--p
This archive was generated by hypermail 2b28 : Wed May 14 2003 - 20:10:47 EEST