[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libunwind] Unwinding using the context passed to a signal handler (

From: David Mosberger
Subject: Re: [libunwind] Unwinding using the context passed to a signal handler (doesn't work)
Date: Fri, 26 Mar 2004 18:01:43 -0800

>>>>> On Tue, 23 Mar 2004 13:29:02 -0800, David Mosberger <address@hidden> said:

  Matthieu> So my questions: - What is dangerous by calling this
  Matthieu> function inside of a signal handler?  - What is the
  Matthieu> safiest way? Dumping the stack and resume the control into
  Matthieu> "normal" mode to analyse the stack once again? [If it is
  Matthieu> possible].

  David> The main concern is deadlock.  If libunwind were to aquire a lock in
  David> unw_get_proc_name() without disabling all signal delivery, you could
  David> get a deadlock if a signal handler was invoked and an attempt were
  David> made to reaquire that same lock.

I looked into this and the current code for unw_get_proc_name()
definitely isn't async-signal safe.  For example, it's calling various
stdio routines (such as fclose()) which aren't async-signal safe.
Worse, POSIX doesn't even guarantee async-signal safety for
mmap()/munmap(), but that just seemed screwed up, because it would
make it virtually impossible to allocate any memory during a signal
handler.  I guess on that one we'll just have to say that it's
specific to the OSes which implement mmap/munmap in a signal-safe way
(which is hopefully the case for all OSes we care about).

As for unw_get_proc_name(): I think the problem is fixable.  If so,
I'll fix the documentation to say that it's signal-safe.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]