[linux-audio-dev] pthreads and signals

[Jack O'Quin]

Paul Davis <paul at linuxaudiosystems.com> writes:

> is there anyone here who has any idea how to handle segv's in a
> linuxthreads-using application? i know that many of you are aware that
> i've used threads a lot in my apps, and grappled with lots of tricky
> signal related issues. however, i continue to see something really
> deeply ugly in linuxthreads: segfaults seem not to be handled in the
> same way as other signals. when a thread in ardour causes a segfault,
> that thread is killed (actually, it becomes a zombie, waiting for its
> parent to exit) and thats the end of the signal handling. for all
> other signals, my code causes them are delivered to a single thread
> that is waiting on all waitable signals except SIGCHLD, and we get
> control there in a useful way.

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."

Of course, the default action for these signals is termination.  But,
what happens if the offending thread tries to mask or ignore a
synchronous signal?

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?  

> its very distressing: a segfault will cause ardour to cease normal
> operation, but nothing knows it has happened. if its in (say) the disk
> butler thread, the GUI will continue working normally, but nothing
> will actually do the right thing.
> 
> has anybody come up with code in which segfaults within threads are
> handled? i have a few ideas on an approach that might work, but i'm
> asking first :)

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.

-- 
  Jack O'Quin
  Austin, Texas, USA