• Uncategorized

About c++ : C-Linux-Binary-terminated-with-signal-SIGKILL—why-loaded-in-GDB

Question Detail

So I fire up my c++ application in GDB, and when it quits, I basically get:

[Thread 0x7fff76e07700 (LWP 6170) exited]
[Thread 0x7fff76f08700 (LWP 6169) exited]
[Thread 0x7fff77009700 (LWP 6168) exited] 
...
Program terminated with signal SIGKILL, Killed. The program no longer exists.
(gdb)

I literally have no idea why this is occuring, why can’t I do a backtrace to see how it exited? Anyone have any ideas? It should never end 🙁

Thanks!

Question Answer

I literally have no idea why this is occuring,

This usually means that either

  • some other process executed a kill -9 <your-pid>, or
  • the kernel OOM killer decided that your process consumed too many resources, and terminated it (effectively the kernel executed kill -9 for it). You should look in /var/log/messages (/var/log/syslog on Ubuntu variants) for traces of that — the kernel usually logs a message when it OOMs some process.

why can’t I do a backtrace to see how it exited?

Because in order to see a backtrace, the process must exist. If it doesn’t exist, it doesn’t have stack, and so can’t have backtrace.

If you are using Unix/Linux you should also be able to type dmesg on your terminal and see the cause of the process terminating. In my case it was indeed OOM. here is a screenshot of my kernel log shortly after the termination

It is possible that the process ran into the cpu time ulimit. Check with ulimit -a from the environment where the process is actually started if “cpu time” is set to anything other than “unlimited”

In my case was a crash (AV). Even with GDB attached I couldn’t catch this violation.
Hope it helps

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.