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 <b...@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 <u9012...@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.

Regards,
William
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to