Messages in this thread | | | Date | Mon, 24 Mar 2014 15:13:22 +0530 | From | Janani Venkataraman <> | Subject | Re: [PATCH 00/33] [RFC] Non disruptive application core dump infrastructure |
| |
On 03/21/2014 08:32 PM, Phillip Susi wrote: > On 3/21/2014 4:17 AM, Karel Zak wrote: >> The gencore command looks like a good idea, but why we need the >> client-server infrastructure? At least at first glance it seems >> like overkill. > Yes, the server seems pointless. > >>> We would like to push this to one of the following packages: a) >>> util-linux b) coreutils c) procps-ng >> d) somewhere near to gdb :-) > gdb already has such a thing; it's called gcore. Kind of makes this > work seem redundant?
Gcore attaches to the process using gdb and runs the gdb gcore command and then detaches. In gcore the dump cannot be issued from a signal handler context as fork() is not signal safe and moreover it is disruptive in nature as the gdb attaches using ptrace which sends a SIGSTOP signal. Hence the gcore method cannot be used if the process wants to initiate a self dump as well. The following link points to a discussion regarding why not gcore.
https://lkml.org/lkml/2013/9/3/122
>
| |