On 29/03/2019 00:05, Jonny Grant wrote:
>
>
> 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
It's not pretty, but this wrapper catches NULL passed at compile time:
std::string make_std_string(const char * const str)
{
// This line ensures: warning: dereference of NULL '0' [CWE-476] [-Wanalyzer-null-dereference]
char b = *str;
std::string s(str);
s[0] = b; // copy it back to avoid unused variable warning
return s;
}
int main()
{
const char * a = NULL;
std::string result = make_std_string(a);
std::cout << result;
}
note, there a PR in latest gcc for an issue, so need to use -Wno-analyzer-use-of-uninitialized-value to avoid std::string having an incorrect warning reported.
