coredump

Similar points to the one in this question have been raised before here and here , and I'm aware of the Google coredump library (which I've appraised and found lacking, though I might try and work on that if I understand the problem better). I want to obtain a core dump of a running Linux process without interrupting the process. The natural approach is to say: if (!fork()) { abort(); } Since the forked process gets a fixed snapshot copy of the original process's memory, I should get a complete core dump, and since the copy uses copy-on-write, it should generally be cheap. However, a critical

I use pstack to analyze core dump files in Solaris How else can I analyze the core dump from solaris? What commands can be used to do this? What other information will be available from the dump? philant You can use Solaris modular debugger,mdb, or dbx. mdb comes with SUNWmdb (or SUNWmdb x for the 64 bits version) package. A core file is the image of your running process at the time it crashed. Depending on whether your application was compiled with debug flags or not,you will be able to view an image of the stack, hence to know which function caused the core, to get the value of the

I have a core file generated on a remote system that I don't have direct access to. I also have local copies of the library files from the remote system, and the executable file for the crashing program. I'd like to analyse this core dump in gdb. For example: gdb path/to/executable path/to/corefile My libraries are in the current directory. In the past I've seen debuggers implement this by supplying the option "-p ." or "-p /=."; so my question is: How can I specify that libraries be loaded first from paths relative to my current directory when analysing a corefile in gdb? Drew Frezell Start

So I wrote buggy code that occasionally crash ... and creates a stackdump file. Using addr2line I can figure out how the program got to the crash point by decoding the addresses on by one. Is there an alternative tool that can ease the debug using stack dumps? Is there a way to to load this information in Insight/Gdb? You can instruct Cygwin to start your gdb debugger just in time when an fault occurs. To achieve this, add error_start=action to the Cygwin environment variable: export CYGWIN="$CYGWIN error_start=gdb -nw %1 %2" Else you can have Cygwin generate a real core dump. export CYGWIN="