|
From: | Janani Venkataraman |
Subject: | Re: [PATCH 00/33] [RFC] Non disruptive application core dump infrastructure |
Date: | Mon, 24 Mar 2014 15:13:22 +0530 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 |
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-ngd) 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
[Prev in Thread] | Current Thread | [Next in Thread] |