[ovs-dev] [PATCH] fatal-signal: Catch SIGSEGV and print backtrace.

Ben Pfaff blp at ovn.org
Fri Sep 20 14:39:20 UTC 2019


On Fri, Sep 20, 2019 at 10:28:36AM -0700, William Tu wrote:
> On Wed, Sep 18, 2019 at 04:27:46PM -0700, Ben Pfaff wrote:
> > On Wed, Sep 18, 2019 at 01:16:37PM -0700, William Tu wrote:
> > > Thanks for the feedback.
> > > 
> > > On Wed, Sep 18, 2019 at 11:30 AM Ben Pfaff <blp at ovn.org> wrote:
> > > >
> > > > On Tue, Sep 17, 2019 at 04:13:24PM -0700, William Tu wrote:
> > > > > The patch catches the SIGSEGV signal and prints the backtrace
> > > > > using libunwind, hopefully makes it easier to debug.
> > > > >
> > > > > Signed-off-by: William Tu <u9012063 at gmail.com>
> > > >
> > > > I guess my experience is that this sort of thing is sometimes useful but
> > > > ultimately causes problems because it tries to call a lot of functions
> > > > that a signal handler is not supposed to call.
> > > 
> > > Do you mean the show_backtrace() tries to call too many functions?
> > > What's the concern about calling lots of functions in a signal handler?
> > 
> > There is no concern about the number of functions but about the specific
> > ones.  Most C library functions are not async-signal-safe, meaning that
> > it is not safe to call them from a signal handler.  There is a list of
> > functions guaranteed to be async-signal-safe in section 2.4.3 "Signal
> > Actions" of the System Interfaces volume of POSIX.  You can find it
> > here: https://pubs.opengroup.org/onlinepubs/9699919799/.  Notably, it
> > doesn't contain the stdio functions like printf() and fflush(), or
> > syslog, and those functions are likely to malfunction if the signal
> > handler interrupts some ongoing operation on a stream.  There's a risk
> > of being caught in some kind of SIGSEGV loop.
> > 
> > I think there needs to be a lot of care if we're going to do this by
> > default.
> 
> Thanks a lot! I wasn't aware of these issue.
> 
> In lib/backtrace.c, it uses GNU backtrace(3) and it's not signal safe.
> Fortunately, the libunwind in this patch with local unwinding is signal
> safe, 
> https://www.nongnu.org/libunwind/man/libunwind(3).html#section_5
> So for v2, I'm thinking about removing the use of printf and fllush.

That sounds like a good idea.  It is still possible to write to stderr
using write().  It might be possible to define some signal-safe vlog
interface for logging to a file, too.


More information about the dev mailing list