Re: Recursive SIGSEGV question

[Jonny Grant <jg@jguk.org>]

[-- Attachment #1: Type: text/plain, Size: 5064 bytes --]



On 28/03/2019 04:59, Xi Ruoyao wrote:
> On 2019-03-27 23:47 +0000, Jonny Grant wrote:
>>
>> On 27/03/2019 21:34, Jonathan Wakely wrote:
>>> On Wed, 27 Mar 2019 at 21:27, Jonny Grant wrote:
>>>> Hi!
>>>>
>>>> Thank you for your reply and input.
>>>>
>>>> Maybe GCC's "libbacktrace" module could be used?
>>>>
>>>> I was wondering if -fsanitize=address would output a backtrace for the
>>>> C++ exception, but it doesn't seem to. Also it actually prevents the
>>>> core being dumped - that's probably not intended?
>>>>
>>>> Compile without Sanitizer, and it does dump the core to a file at least!
>>>>
>>>> $ export UBSAN_OPTIONS=print_stacktrace=1
>>>
>>> This is a UBsan option.
>>>
>>>> // g++-8 -fsanitize=address -Wall -o exception exception.cpp
>>>
>>> But you're not using UBsan.
>>>
>>>> #include <vector>
>>>> int main()
>>>> {
>>>>        std::vector<int> v;
>>>>        return v.at(0);
>>>> }
>>>>
>>>>
>>>> $ ./exception
>>>> terminate called after throwing an instance of 'std::out_of_range'
>>>>      what():  vector::_M_range_check: __n (which is 0) >= this->size()
>>>> (which is 0)
>>>> Aborted
>>>
>>> There's no undefined behaviour or memory corruption here, so it's not
>>> surprising that UBsan and Asan don't print anything.
> 
> C++ exception is a well-defined language feature.  There are even guys
> (mis)using it in cases we normally use "if (...) {...}"
> 
>> Ok I see, thank you for pointing this out.
>>
>> I did wonder, as -fsanitize=address seems to inhibit the core dump that
>> is otherwise created by the abort() that appears to be called - is that
>> a known issue?
>>
>> $ g++-8 -Wall -o exception exception.cpp
>> jonny@asus:~/code/crash$ ./exception
>> terminate called after throwing an instance of 'std::out_of_range'
>>     what():  vector::_M_range_check: __n (which is 0) >= this->size()
>> (which is 0)
>> Aborted (core dumped)
>> $
>>
>> Usually I just load the core dump into GDB to take a look at it.
> 
> It seems so.  I don't know if this is a intentional feature or an oversight.
> 
>>> If you want a stack trace for exceptions that terminate the process
>>> then you could install a custom terminate handler which does that.
>>> Libstdc++'s default terminate handler just prints the message above,
>>> which includes the type of the exception and if it's a type derived
>>> from std::exception, the what() string stored in it.
>>
>> Yes, I'd love to have a stack trace for exceptions that terminate the
>> process. Do you know a simple example you can refer me to?  I've looked
>> and there are people using boost::stacktrace::stacktrace() but I'd
>> rather not link to boost as a dependency.
>>
>> It would be great if there was a glibc option to do this, or GCC could
>> insert it.
> 
>> Otherwise we each need to insert our own stack tracers...
>>
>> Found this:
>> https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
>>
>> I added this (attached) to a C++ exception handler, but there's no file
>> and line numbers. Other examples resort to calling addr2line! Seems a
>> bit over the top for us each to code our own stack tracer... Or reading
>> symbols etc. Am I asking too much for a general print_backtrace() in
>> libc or elsewhere ?
> 
> Providing backtrace with file:line requires to parse debug info.
> 
> glibc libSegFault.so just record a stack bracktrace w/o line numbers.  The shell
> wrapper catchsegv convert addresses into line numbers calling addr2line.

Hi!

libSegFault.so seems like a big module! If it only records stack frames 
like the backtrace() and backtrace_symbols() functions get in around 10 
lines of code. Maybe libSegFault does a lot more than it seems. I was 
using these functions
https://www.gnu.org/software/libc/manual/html_node/Backtraces.html


catchsegv doesn't show line numbers for me:

backtrace:
./loop(+0x9ae)[0x55ee7f23e9ae]
./loop(+0xa03)[0x55ee7f23ea03]
./loop(+0xa03)[0x55ee7f23ea03]
[repeats]

This is the stack overflow testcase. Please find attached.

The file does have the info:
$ addr2line -e loop 0xa03
/home/jonny/code/crash/loop.cpp:7 (discriminator 4)


> 
> If you don't want to call addr2line (or other tools) you'll need DWARF parser in
> the executable. Why should we bloat the executable with a lot of code which
> should be in (and has been in) a debugger?
> 
> For a comparision, Go provides a good stack backtrace at panics.  But how big a
> Go executable is?  A "hello world" takes 1997502 bytes!  While a C++ one
> compiled by G++ is 22088 bytes (with debug info).

My little test exception file leaps up from 31K to 81K when compiled 
with backtrace() and backtrace_symbols()  A lot of increase... 
Considering they are library functions I am surprised its 50K bigger. 
I've not attached that program, but can share if needed..


> If you need a backtrace in debug, just call a debugger.  If you think you'll
> need it in _release_, I believe the right thing to do is catching the exceptions
> (or handle the signals) you care and log them into a log file or a syslog
> facility.

Sounds good! Yes, that sounds good.

Jonny

[-- Attachment #2: loop.cpp --]
[-- Type: text/x-c++src, Size: 175 bytes --]

// g++-8 -ggdb -g -O0 -o loop loop.cpp

#include <string>

static void func(std::string f, int g)
{
    func(f.c_str(), g);
}

int main()
{
    func("a", 0);

    return 0;
}