14 May
2003
14 May
'03
2:59 p.m.
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