What's the linux equivalent to Win32's DBGHELP library? I worked on a game once that had a linux build that would dump a stack out when it aborted, but I never bothered to look at how it was doing this.

When a UNIX application terminates improperly, it will dump core. Which means that it will write the program memory to a file in the same directory as the binary, named either core, processname.core or something similar. You can limit the size of core files by setting the limit coredumpsize in the shell to a suitable limit, or using unlimited for always creating core files.

The files can then be loaded together with the binary in GDB or any other suitable debugger to get the exact state of the process when it died.

Quote: Original post by Zao
When a UNIX application terminates improperly, it will dump core. Which means that it will write the program memory to a file in the same directory as the binary, named either core, processname.core or something similar. You can limit the size of core files by setting the limit coredumpsize in the shell to a suitable limit, or using unlimited for always creating core files.

The files can then be loaded together with the binary in GDB or any other suitable debugger to get the exact state of the process when it died.

I'm sorry I don't mean to sound like a jerk or anything but having used UNIX/Linux -like stuff starting with SCO XENIX/286 since the mid-80s, I'm fairly well aware of how to do such things. :D

Anyway, for the first time I've encountered a situation where I need to be able to dump a stack out of a running program from the program thats running, and I know this is possible because I've seen it done. :D

Thanks.

You could try gcore.

There is also a signal that will terminate a program with a core dump I think.
Im not sure which signal it is and how to do it. Just an idea.

libunwind?

It depends how much work you want to do... I haven't found a simple, portable, and reliable solution that doesn't require me to do any work, yet.

glibc provides a set of functions for producing backtraces. They're fairly portable, as long as all of your targets are using glibc. Look for backtrace()/backtrace_symbols() in the Debugging Support/Backtraces section of the glibc manual. This is probably the easiest method.

Samba has a clever method for producing debug information--they catch faults and then programmatically fire up gdb in another process, attach to the faulting process, and inspect whatever is needed that way.

If you can be sure that the code you want to inspect has been compiled with frame pointers (or the ABI provides another easy way to walk back through frames), you could write some simple code yourself, but going much beyond what glibc's backtrace functionality already does will require quite a bit of detail knowledge about assembler, debug formats (e.g. DWARF 2) and each platform's ABI... and generally, that stuff is largely only documented via code.

If you want to go further than that, the most obvious, but not necessarily easiest, thing to do would be to look at the sources for gdb. Closely related to that, libbfd provides a way to manipulate object files. Unfortunately, the documentation is awful, so your best bet is to read the source existing code that uses libbfd--namely, binutils and gdb. Looking at the existing source of other debugging tools like valgrind, winedbg/winedump, etc. might be useful, but won't give you a quick solution either.

libsigsegv provides a fairly portable fault handling mechanism. libiberty for demanging C++ symbol names and some other utility stuff. If you're using C++, take a look at libcwd. There are probably quite a few other "debug helper" libraries available, but I can't think of the names of them right now.

Quote: Original post by 255
libunwind?

Sadly, that library is pretty IA64 specific. There's a small amount of IA32 and PA-RISC support, but not much.

Exactly what I was looking for. Thanks!!!