gcore: Obtain core dump of current running application

March 24th, 2008 mysurface Posted in Admin, Developer, gcore, gdb, pgrep | Hits: 71546 | 5 Comments »

Core dump is always developer’s friends and can be admin user’s nightmare. Developer’s can always get some clue of what’s going wrong through the core files, given that the apps is compiled with -g.

In order to get core dump generated, we must enable the core through ulimit. Generate coredumps to help developer for debugging introduce you how to enable core dump as well as how to access the info through gdb.

Sometimes, the app may hangs there, reject to response. This is really headache for the programmers to debug without looking into its internal, investigate whats going wrong. You may choose to debug it directly through gdb. Or maybe you would like to generate the core file and send it to your development team. You can choose to abort it and collect the core file.

But what if abort is not the case? and you still want your apps to run, but wanna take a snapshot of current running apps into a core file?

Thanks to W.G. that leaves me a comment introducing gcore to us, that consider a godsend, and I think this command is really useful. Yes, a simple command that allow us to get core images of running processes.

Let say I am running an app call matrix (a simple ncurses sample app that emulates the words flow). I can obtain the process id by using pgrep and pass to gcore like this:

gcore `pgrep matrix`

The core file you obtain will be core.pid format like this:

core.6129

A tiny nice option gcore support you change your output core file’s name with -o

gcore -o matrix `pgrep matrix`

The line above will produce the core file as below:

matrix.6129

Freebsd provides a better gcore, it does allow you to temporary STOP the running process while gathering the core image, and resume it when done.

gcore -s `pgrep matrix`

5 Responses to “gcore: Obtain core dump of current running application”

  1. You can stop the process and re-start it manually on systems which do not do so… use ‘kill -l’ to find the SIGSTOP and SIGCONT signals, and then wrap the call to gcore with them. If you do this frequently, you can define a shell alias for gcore that does all of it, though I did not do so below:

    mbt@sage:~/Desktop$ kill -19 6845 ; gcore 6845 ; kill -18 6845
    Using host libthread_db library “/lib/tls/i686/cmov/libthread_db.so.1″.
    [Thread debugging using libthread_db enabled]
    [New Thread 0xb7020720 (LWP 6845)]
    [New Thread 0xb56c4b90 (LWP 6911)]
    [New Thread 0xb6088b90 (LWP 6871)]
    0xb7f69410 in __kernel_vsyscall ()
    Saved corefile core.6845

  2. Good idea! Thanks Michael =)

  3. [...] to take a dump. This can get handy sometime while getting a good snapshot. Michael B. Trausch gcore: Obtain core dump of current running application — see comment Possibly related posts: (automatically generated)Mono 1.2.5.1_3 Installer的问题 Tags: core, [...]

  4. Where is the source for this?

  5. As a web resource for corporations and technology enthusiasts to observe the latest and biggest advancements in Unified Communications, IP Telephony, Hosted Communications and VoIP.

Leave a Reply