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
// 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;
}
