0

I have a C++ program, running on Linux. It appears that if an uncaught exception occurs, the default action is to send SIGABRT to the process, which (by default) terminates the process. I have crash dumps set up; some random end-user sends me the crash dump. I load the dump, load up my symbols, ask for a stack trace, and get... this:

>>> bt
#0  0xf7770e39 in ?? ()
#1  0x00000000 in ?? ()

Obviously, this tells me nothing.

How to unconditionally force GDB to tell me what actually went wrong??

I presume what happens here is an exception is thrown, the entire stack slowly gets unwound, until eventually when the exception reaches the top, it runs some code to send SIGABRT (and that code is presumably all that's left on the stack). Is there anything I can do to get at the data telling me what exception was thrown or where it was thrown from? Without this information, the customer's issue is basically unfixable.

MathematicalOrchid
  • 61,854
  • 19
  • 123
  • 220
  • 3
    It tells me that the stack is corrupted. Code review, building with verbose warnings enabled (and treated as errors) and using static analysis tools are the ways to find out these kind of things. – Some programmer dude Sep 25 '19 at 10:15
  • Rebuild you program with address sanitizer enabled (clang and gcc tooling option) and run program again. It will help you find the actual issue. – Marek R Sep 25 '19 at 10:31
  • @Someprogrammerdude I don't know, man... From what I've seen, the C++ runtime tends to do "strange" things which seem to confuse GDB. I get the impression parts of it are written in assembly rather than C/C++, so they don't always follow the same calling conventions. – MathematicalOrchid Sep 25 '19 at 10:36
  • Perhaps the transfer of the stack dump corrupted it? – Raedwald Sep 25 '19 at 10:43
  • Are you sure it is `SIGABRT`? What is the output of `p $_siginfo`? – ks1322 Sep 25 '19 at 11:07
  • @ks1322 `si_signo = 6`, so... – MathematicalOrchid Sep 25 '19 at 12:34
  • "I presume ..." -- is incorrect: if you don't have an active `try` block, *no* unwind will happen and `abort()` is called with the complete stack still intact. You just can't decode that stack due to the system library mismatch. – Employed Russian Sep 25 '19 at 18:42

0 Answers0