Re: [linux-audio-dev] pthreads and signals

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] pthreads and signals
From: Jack O'Quin (joq_AT_io.com)
Date: Wed May 14 2003 - 19:21:08 EEST


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 14 2003 - 19:38:23 EEST