Обсуждение: Launching debugger on self on SIGSEGV
Hi,
The attached patch registers a signal handler for SIGSEGV and launches GDB in batch mode on its own pid so that the stack leading to the SEGV can be dumped in the server logs. Also attached is an example of the stack dumped by gdb in server log file (caused by a `kill -segv nnn` on the backend).
Since this patch calls fork() inside a signal handler, I investigated a bit and found that, per POSIX, fork() is asynch-signal-safe and hence it can be called inside a handler.
This in itself might not be very useful because I haven't seen many crash reports in the community, but it can be extended to dump stack on Assert so that it helps developers and our beta testers. It can also be used to dump stack of a process we are about to kill for deadlock reasons, and before certain PANIC conditions too.
Right now it works only for gdb (setting the GUC to true actually check for the presence of gdb), but it can be made generic, they way our archive_command etc. work, so that we take a string and replace certain parameters with binary path and pid so that any debugger can be used.
It also looks pretty easy to port it to Windows since all we really want to do is create an external process with certain parameters, and CreateProcess() is all we need. I haven't investigated seriously about that but of there's interest in this patch then I can spend some time on that too.
Regards,
--
The attached patch registers a signal handler for SIGSEGV and launches GDB in batch mode on its own pid so that the stack leading to the SEGV can be dumped in the server logs. Also attached is an example of the stack dumped by gdb in server log file (caused by a `kill -segv nnn` on the backend).
Since this patch calls fork() inside a signal handler, I investigated a bit and found that, per POSIX, fork() is asynch-signal-safe and hence it can be called inside a handler.
This in itself might not be very useful because I haven't seen many crash reports in the community, but it can be extended to dump stack on Assert so that it helps developers and our beta testers. It can also be used to dump stack of a process we are about to kill for deadlock reasons, and before certain PANIC conditions too.
Right now it works only for gdb (setting the GUC to true actually check for the presence of gdb), but it can be made generic, they way our archive_command etc. work, so that we take a string and replace certain parameters with binary path and pid so that any debugger can be used.
It also looks pretty easy to port it to Windows since all we really want to do is create an external process with certain parameters, and CreateProcess() is all we need. I haven't investigated seriously about that but of there's interest in this patch then I can spend some time on that too.
Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Вложения
Gurjeet Singh <singh.gurjeet@gmail.com> writes:
> The attached patch registers a signal handler for SIGSEGV and launches
> GDB in batch mode on its own pid so that the stack leading to the SEGV can
> be dumped in the server logs.
Did you not read the thread last week about how we did not want any such
thing?
Quite aside from any postgres-specific reasons not to have any added
delay in the signal-to-database-shutdown path, this patch makes a bunch
of untenable assumptions about whether or where gdb is installed,
whether there are usable debug symbols available, whether gdb's output
will go somewhere useful, etc etc. And on top of all that, it adds *no
functionality whatsoever* compared to a post-mortem gdb run on the core
file.
regards, tom lane
On Mon, Jul 11, 2011 at 12:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Unfortunately, I did not. I'll catch up on it.
I agree that it makes a bunch of assumptions, that's why I proposed that we make it user configurable parameter, like archive_command, so that users (or their packagers) can provide the command and all the relevant options.
Gurjeet Singh <singh.gurjeet@gmail.com> writes:Did you not read the thread last week about how we did not want any such
> The attached patch registers a signal handler for SIGSEGV and launches
> GDB in batch mode on its own pid so that the stack leading to the SEGV can
> be dumped in the server logs.
thing?
Unfortunately, I did not. I'll catch up on it.
Quite aside from any postgres-specific reasons not to have any added
delay in the signal-to-database-shutdown path, this patch makes a bunch
of untenable assumptions about whether or where gdb is installed,
whether there are usable debug symbols available, whether gdb's output
will go somewhere useful, etc etc. And on top of all that, it adds *no
functionality whatsoever* compared to a post-mortem gdb run on the core
file.
I agree that it makes a bunch of assumptions, that's why I proposed that we make it user configurable parameter, like archive_command, so that users (or their packagers) can provide the command and all the relevant options.
Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
EnterpriseDB Corporation
The Enterprise PostgreSQL Company