On 9/12/2013 12:45 AM, Suzuki K. Poulose wrote: > 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.
Oh, I did think the fork() is used for no application stop dump. But it is incorrect. Hmm. However, if an application _itself_ want to dump itself. They can avoid to use signal handler properly. I'm missing the point of this discussion completely. So, I'd keep silence while. > > So, if the application wants to initiate the dump from a signal handler > context, it may lead to trouble. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/