3

The application I'm working on crashed on the client machine and I have the following callstack from the core dump:

#0  SignalKill () at /MyBuildDir/lib/c/kercalls/aarch64/SignalKill.S:8
#1  0x0000000001041d2c in abort () at /MyBuildDir/lib/c/ansi/abort.c:92
#2  0x000000007b1688d0 in __gnu_cxx::__verbose_terminate_handler () at ../../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x000000007b166400 in __cxxabiv1::__terminate (handler=) at ../../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x000000007b165238 in __cxa_call_terminate (ue_header=ue_header@entry=0x109dd5f0) at ../../../../../libstdc++-v3/libsupc++/eh_call.cc:54
#5  0x000000007b165d68 in __cxxabiv1::__gxx_personality_v0 (version=, actions=6, exception_class=, ue_header=0x109dd5f0, context=0x100c3bd0) at ../../../../../libstdc++-v3/libsupc++/eh_personality.cc:676
#6  0x00000000819f66f0 in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x109dd5f0, context=context@entry=0x100c3bd0) at ../../../libgcc/unwind.inc:62
#7  0x00000000819f6f30 in _Unwind_Resume (exc=0x109dd5f0) at ../../../libgcc/unwind.inc:230
#8  0x000000008052cf04 in MyClass::MyFunction(unsigned int)
...

Looking at the call stack I assume this is caused by an uncaught exception which leads to std::terminate. Unfortunately I can't reproduce this behavior on the development machine.

Can you please help me with some debugging techniques to determine which exception was thrown? MyClass::MyFunction doesn't have any throw, but it uses several std:: types. May I assume the throw was somehow inlined in MyClass::MyFunction considering the next frame in the call stack is _Unwind_Resume? May I exclude throw during stack unwinding(double throw)?

EDIT 1:

The executable was compiled with GCC 5.4.0 and the runtime is libstdc++.so.6.0.21

EDIT 2: values on frame 7

(gdb) info locals
this_context = {reg = {0x100c3760, 0x100c3768, 0x100c3770, 0x100c3778, 0x0 <repeats 15 times>, 0x100c3780, 0x100c3788, 0x100c3790, 0x100c3798, 0x100c37a0, 0x100c37a8, 0x100c37b0, 0x100c37b8, 0x100c37c0, 0x100c37c8, 0x100c3750, 0x100c3758, 0x0 <repeats 41 times>, 
    0x100c37d0, 0x100c37d8, 0x100c37e0, 0x100c37e8, 0x100c37f0, 0x100c37f8, 0x100c3800, 0x100c3808, 0x0 <repeats 18 times>}, cfa = 0x100c3f90, ra = 0x8052cf04 <MyClass::MyFunction(unsigned int)+860>, lsda = 0x0, bases = {tbase = 0x0, dbase = 0x0, 
    func = 0x819f6eb8 <_Unwind_Resume>}, flags = 4611686018427387904, version = 0, args_size = 0, by_value = '\000' <repeats 97 times>}
cur_context = {reg = {0x100c3760, 0x100c3768, 0x100c3770, 0x100c3778, 0x0 <repeats 15 times>, 0x100c3fa0, 0x100c3fa8, 0x100c3fb0, 0x100c3fb8, 0x100c3fc0, 0x100c3fc8, 0x100c3fd0, 0x100c3fd8, 0x100c3fe0, 0x100c3fe8, 0x100c3f90, 0x100c3f98, 0x0 <repeats 41 times>, 
    0x100c37d0, 0x100c37d8, 0x100c37e0, 0x100c37e8, 0x100c37f0, 0x100c37f8, 0x100c3800, 0x100c3808, 0x0 <repeats 18 times>}, cfa = 0x100c41b0, ra = 0x8011f384 <ClientClass::~ClientClass()+204>, lsda = 0x8229ebd2, bases = {tbase = 0x0, dbase = 0x0, 
    func = 0x8011f2b8 <ClientClass::~ClientClass()>}, flags = 4611686018427387904, version = 0, args_size = 0, by_value = '\000' <repeats 97 times>}
(gdb) p exc
$1 = (struct _Unwind_Exception *) 0x109dd5f0
(gdb) p *exc
Cannot access memory at address 0x109dd5f0
Mircea Ispas
  • 20,260
  • 32
  • 123
  • 211
  • 1
    If you have a coredump, I would try inspecting the `exc` variable in frame 7 or the disassembly of the code around the instruction pointer in frame 8. I don't know if QNX does address randomization, but if it does not you could match the address in frame 8 to a location in your own copy of the binary. – Botje Oct 02 '20 at 08:21
  • This is why having a top-level exception logger that can capture details and dump them out can help. Many applications these days have a crash reporter that does precisely this. Does that address help in pinning down where in that executable the code blew out? I'd look very closely at that code because if the exception originated there that's different from something that bubbled through it. – tadman Oct 02 '20 at 08:26

0 Answers0