[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-libsigsegv] libsigsegv
From: |
Jonny Grant |
Subject: |
Re: [bug-libsigsegv] libsigsegv |
Date: |
Thu, 11 Apr 2019 00:17:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
Hi Bruno!
On 11/04/2019 00:08, Bruno Haible wrote:
Hi,
Jonny Grant wrote:
I wrote the attached, it's pretty simple and outputs a
little stack trace. I was just hoping for something a little more
advanced than my addr2line wrapper! but at least I have something for
the moment to use.
Ah, you want to build some crash diagnostic feature, like 'apport'?
https://wiki.ubuntu.com/Apport
yes, exactly!
Although we don't often get crashes, just unhandled C++ exceptions. Or
NULL ptr dereference SIGSEGV (so backtrace seems ok).
Generally, such crash diagnostics are more easily realized from a
different process than from the same process, for three reasons:
1) If something is broken in the current process, it may affect the
ability of the crash diagnostic to function.
2) External tools have easier access to 'addr2line' or 'gdb'.
Good point
Yes, maybe we should just use a wrapper to launch the program. Or load
the core after the unhandled C++ exception calls abort().
gdb -nx --command=my_gdbtrace.txt --args myprogram
From my experience I've always been fortunate that stack trace is
generally pretty accurate with gdb, maybe I've been lucky.
3) On some platforms, hopping from frame to frame in a stack trace
is nontrivial; this is 'libunwind's job. When there was a signal,
there is usually no reliable connection between the frame above
the SIGSEGV and the frames below the SIGSEGV. An external tool
like gdb avoids this because it does not need to add further frames
to the stack.
Yes, I think you've just been lucky so far.
Bruno
Cheers, Jonny