Nitin Verma’s Blog

Generating core dumps of running processes

Posted on: December 25, 2008

// Refer to my previous post
// http://vermanitin.wordpress.com/2008/12/25/helloworld-flex/
$ ps -eafwww | grep hw | grep -v grep
nitinv   11703  6642  0 16:42 pts/7    00:00:00 ./hw

$ gcore -o hw.core 11703
(no debugging symbols found)
Using host libthread_db library "/lib/i686/nosegneg/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x00fac402 in __kernel_vsyscall ()
Saved corefile hw.core.11703

$ gdb ./hw hw.core.11703
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/i686/nosegneg/libthread_db.so.1".


warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/i686/nosegneg/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/i686/nosegneg/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
(no debugging symbols found)
Core was generated by `/home/nitinv/codes/grammar/hw'.
#0  0x00fac402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00fac402 in __kernel_vsyscall ()
#1  0x00b1d1d3 in __read_nocancel () from /lib/i686/nosegneg/libc.so.6
#2  0x00abd588 in _IO_file_read_internal () from /lib/i686/nosegneg/libc.so.6
#3  0x00abe930 in _IO_new_file_underflow () from /lib/i686/nosegneg/libc.so.6
#4  0x00abf02b in _IO_default_uflow_internal () from /lib/i686/nosegneg/libc.so.6
#5  0x00ac039d in __uflow () from /lib/i686/nosegneg/libc.so.6
#6  0x00aba10c in getc () from /lib/i686/nosegneg/libc.so.6
#7  0x08048fad in yy_get_next_buffer ()
#8  0x08048c84 in yylex ()
#9  0x08048655 in main ()

This even works with ulimit not set ;)

$ ulimit -a | grep core
core file size          (blocks, -c) 0

Neat way to stop and restart your process 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

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: