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.
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).
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.
--
Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
