Re: RFD: Non-Disruptive Core Dump Infrastructure

["Suzuki K. Poulose" <suzuki@in.ibm.com>]

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