Messages in this thread | | | Date | Thu, 12 Sep 2013 10:15:37 +0530 | From | "Suzuki K. Poulose" <> | Subject | Re: RFD: Non-Disruptive Core Dump Infrastructure |
| |
On 09/12/2013 12:57 AM, KOSAKI Motohiro wrote: > (9/3/13 4:39 AM), Janani Venkataraman wrote: >> Hello, >> >> We are working on an infrastructure to create a system core file of a >> specific >> process at run-time, non-disruptively. It can also be extended to a >> case where >> a process is able to take a self-core dump. >> >> gcore, an existing utility creates a core image of the specified >> process. It >> 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. > > Maybe I'm missing something. But why gcore uses c-level fork()? gcore > need to > call pthread-at-fork handler? No. gcore need to flush stdio buffer? No. > Let me clarify. If an application wants to dump itself, it has to do a fork() and then exec the gcore with the pid of the appication to generate the dump.
So, if the application wants to initiate the dump from a signal handler context, it may lead to trouble.
Thanks Suzuki
| |