views:

33

answers:

1

Anytime I have a badly behaving process (pegging CPU, or frozen, or otherwise acting strangely) I generally kill it, restart it and hope it doesn't happen again.

If I wanted to explore/understand the problem (i.e. debug someone else's broken program as it's running) what are my options?

I know (generally) of things like strace, lsof, dmesg, etc. But I'm not really sure of the best way start poking around productively.

Does anyone have a systematic approach for getting to the bottom of these issues? Or general suggestions? Or is killing & restarting really the best one can do?

Thanks.

+1  A: 

If you have debugging symbols of the program in question installed, you can attach to it with gdb and look what is wrong there. Start gdb, type attach pid where pid is the process id of the program in question (you can find it via top or ps). Then type Ctrl-C to stop it. Saying backtrace gives you the call stack, that means it tells which line of code is currently running and which functions called the currently running function.

fschmitt