Re: Crash dumps

On Mon, 04 Jul 2011 12:58:46 +0800, Craig Ringer wrote:
> On 15/06/2011 2:37 AM, Radosław Smogura wrote:
>> Hello,
>>
>> Because, I work a little bit on streaming protocol and from time to
>> time
>> I have crashes. I want ask if you wont crash reporting (this is one
>> of
>> minors products from mmap playing) those what I have there is mmaped
>> areas, and call stacks, and some other stuff.
>
> Core files already contain all that, don't they? They omit shared
> memory segments by default on most platforms, but should otherwise be
> quite complete.
>
> The usual approach on UNIXes and linux is to use the built-in OS
> features to generate a core dump of a crashing process then analyze
> it
> after the fact. That way the crash is over as fast as possible and
> you
> can get services back up and running before spending the time, CPU
> and
> I/O required to analyze the core dump.

Actually this, what I was thinking about was, to add dumping of GUC,
etc. List of mappings came from when I tired to mmap PostgreSQL, and due
to many of errors, which sometimes occurred in unexpected places, I was
in need to add something that will be useful for me and easy to analyse
(I could simple find pointer, and then check which region failed). The
idea to try to evolve this come later.

I think report should looks like:
This is crash report of PostgreSQL database, generated on
Here is list of GUC variables:
Here is list of files:
Here is backtrace:
Here is detailed backtrace:
Here is list of m-mappings (you may get what library are linked in)
Here is your free memory
Here is your disk usage
Here is your custom addition

>> This based reports works
>> for Linux with gdb, but there is some pluggable architecture, which
>> connects with segfault
>
> Which process does the debugging? Does the crashing process fork() a
> copy of gdb to debug its self?
>
> One thing I've been interested in is giving the postmaster (or more
> likely a helper for the postmaster) the ability to handle "backend is
> crashing" messages, attach a debugger to the crashing backend and
> generate a dump and/or backtrace. This might be workable in cases
> where in-process debugging can't be done due to a smashed stack, full
> heap causing malloc() failure, etc.

Currently I do everything in segfault handler (no fork), but I like the
idea of fork (in segfault), this may resolve some problems.

Regards,
Radosław Smogura