I am working on a project using Eclipse CDT and am encountering what seems to be an infinite loop.
When debugging an application from within Eclipse, I can easily retrieve and examine the call stack when the process terminates abnormally (segfault being the most common one) or when I hit a breakpoint.
If I run into an infinite loop without knowing which statements are looping, a stack trace would give me a rough idea of the functions to look at. How can I tell Eclipse to get me a stack trace of whatever the process is doing right now (in the absence of a breakpoint or segfault)?
My hack for that so far is
killall -SIGSEGV $process_name
(replacing $process_name with the name of the process you are trying to debug). This will cause the process to behave as if it had segfaulted, i.e. stopping it and giving you the call stack of whatever the process was executing at the time.
Is there a cleaner way of achieving the same?
A slightly cleaner way is:
killall -SIGCONT $process_name
This sends a CONT (continue) signal to the process. The primary purpose of this signal is to continue a process after it has been sent a STOP signal. When sent to a process that isn’t stopped, it does nothing.
However, if the process is being debugged in Eclipse (which in turn relies on gdb for debugging), this will stop execution and cause a stack trace to displayed.
Unlike with -SIGSEGV (or other signals that tell the process to dump its core or terminate), you can then hit the Resume button and continue to run your process. The UX is close to what would happen after hitting a breakpoint, except Eclipse will report a different reason for suspending execution.
Note that if you are doing anything that messes with signal processing by your process, this might not work as expected.
No idea if there’s anything that can be triggered from the Eclipse UI, though.