32

In my application, I handle SIGSEG to produce a backtrace and call abort() to generate a core dump.

If I now run a gdb-post-mortem analysis of the core, the thread which caused the SEGFAULT is no longer visible. Is there anything I can do so I see the cause for the SEGFAULT?

Dharman
  • 30,962
  • 25
  • 85
  • 135
Martin C.
  • 12,140
  • 7
  • 40
  • 52
  • 2
    Are you also doing other work in the handler? Why not just let the OS use its default behavior to leave a core for you? – Mark B Apr 16 '10 at 14:43
  • Just creating a backlog to stderr and then calling abort(). – Martin C. Apr 16 '10 at 16:54
  • Please specify your OS, and what exactly you observe in GDB. On Linux (and every other UNIX I can think of) the SIGSEGV handler will run in the thread which caused SIGSEGV in the first place. If that hander calls abort(), then the core dump will contain that thread as thread #1, and there will be no problem finding exactly which instruction and what call stack caused the problem. Since you are having difficulties, you are either on some "strange" OS, or you are not correctly describing what you actually observe. – Employed Russian Apr 17 '10 at 04:17
  • 1
    I am on Linux, Ubuntu 9.10 specifically, 32bit. And no, the SIGSEGV is called on the main thread while the segfault happened on another thread. I currently cannot reproduce the problem, as it was a single ocurance I could not reproduce up to now. – Martin C. Apr 17 '10 at 20:54

1 Answers1

24

You can use command thread apply all bt or thread apply all bt full to get backtraces of all threads. Might be useful.

By the way if you get rid of you handler will your OS create a core file?

  • Currently I use the handler to write a backtrace to stderr, so I have anything, as I could not get anything out of the core-file. I have to try if the default handler will produce "better" core dumps. – Martin C. Apr 16 '10 at 13:53
  • 4
    `ulimit -c unlimited` and see what core you will get without any handler. –  Apr 16 '10 at 14:02
  • @skwllsp, is there a way to know exactly which thread caused the SIGSEGV? Did you mean that it is actually not possible to know and the back traces have to be used to find it? – russoue Jan 05 '15 at 20:10
  • 2
    Usually, `gdb` (when used to analyze a core file) prints stacktrace of a thread that caused a coredump with command `bt`. This is a default behaviour. The question actually was about an opposite situation when a coredump was not in the first thread. That is why I recomended to get backtrace of all threads. –  Jan 06 '15 at 17:04