bug-libsigsegv
[Top][All Lists]
Advanced

[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



reply via email to

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