0

I have web daemon and request that makes it fail with SIGSEGV. So i start daemon, attach with gdb, continuing, send request and getting this:

$ gdb attach -p 630066

(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)

How to make gdb print stacktrace before killing application? Application do not have subprocesses, just threads.

Thanks.

brachistochron
  • 321
  • 1
  • 11
  • Can you rebuild web daemon with `-fstack-protector-all`? Probably you have stack overflow somewhere in daemon. – ks1322 Jun 20 '17 at 14:46

2 Answers2

2

Your GDB session indicates that you have not attached all threads of the multithreaded process, and some other thread (one you didn't attach) ran into SIGSEGV and terminated the entire process.

Another (somewhat unlikely) possibility is that you are using a very old version of GDB, one which still has this bug in it (the bug was fixed in 2009).

When using gdb -p NNNN you need to be careful and specify correct process id. pgrep daemon-name or ps aux | grep daemon-name should give you a good idea which process to attach.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • I found, that if run program under gdb (from start not by attaching) it correctly stops and shows stack. Still don't get what is cause of such behavior. "Your GDB session indicates that you have not attached all threads of the multithreaded process" - I was confident that gdb start looking for all threads (my program have only pthreads not forks) when attached. Whatever thread i attached. – brachistochron Jun 28 '17 at 15:50
  • @brachistochron "I was confident ...". Your confidence is wrong: GDB will attach all threads IFF you given it the process id (aka PID of the main thread), but only one thread if you give it thread-id of non-main thread. – Employed Russian Jun 28 '17 at 19:04
-1

Just enter backtrace or bt right in the gdb shell after getting SIGSEGV. To explore stack trace for each separate thread, start with info thread, then choose the thread you need, for example thread 3 and then type bt to see the stack trace for that thread.

Alexander Lapenkov
  • 585
  • 2
  • 9
  • The problem is this line "The program no longer exists". To examine stack of process i should have process alive, but it's dead. – brachistochron Jun 20 '17 at 13:46
  • You can collect core dump and analyze it with gdb – Alexander Lapenkov Jun 20 '17 at 13:51
  • As far as i understand you still need process alive for making coredump. I just have process that finished instantly after getting SIGSEGV. How can i get this coredump? – brachistochron Jun 20 '17 at 14:18
  • @brachistochron https://stackoverflow.com/questions/17965/how-to-generate-a-core-dump-in-linux-when-a-process-gets-a-segmentation-fault – Alexander Lapenkov Jun 20 '17 at 14:21
  • Could you please tell me specific sequence of actions that i should do? I can't find nothing useful in that post. It's all about cases when gdb actually stops execution of process with SIGSEGV (which is not true for my case). So maybe i miss something? – brachistochron Jun 20 '17 at 14:38