Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On 4/10/2010 8:27 PM, Heikki Linnakangas wrote:
> On 04.10.2010 15:21, Craig Ringer wrote:
>> Thinking about it, a possibly better alternative is to ship it as a
>> library as is done with the pl/pgsql debugger, and use (I think)
>> shared_preload_libraries to load it when desired. That way there's zero
>> cost if disabled, though a somewhat higher cost if enabled.
>>
>> Hmm. That'll let me put a test version together that'll work with 9.0 as
>> well, so that seems like a no-brainer really, it's just a better way to
>> do it. Time for a Pg-on-windows build, yay.
>
> If it's not a lot of code, it's better to have it built-in always.
> Loading extra libraries in debug-mode could lead to heisenbugs.

It turns out that the basic minidumps are small (21kb here) and very
fast to generate. It may well be worth leaving it enabled all the time
after all. I just need to time how long the handler registration takes -
though as LOAD of the current handler implemented as a contrib module
takes 2.1ms, and LOAD of an module with an empty _PG_init() also takes
2.1ms, I'm guessing "not long".

I've attached an early version for people to play with if anyone's
interested. It currently contains a bunch of elog() messages to report
on its progress - though I'm not at all sure elog() should be used in
the final version given that Pg is crashing at the time the handler is
called and there's no guarantee elog() is safe to call. It also doesn't
offer any way to set the dump type yet, it's always the minimal dump
with exception info, registers and stack only. Finally, a "crashme"
function is included to trigger a reliable unhandled exception on
demand, for initial testing.

Usage with Pg built from source on Windows:

- Drop crashdump.c and the Makefile in contrib/crashdump
- Run build.bat and install.bat
- Create a "crashdumps" directory inside your datadir, and make
sure the server has read/write/create permission on it.
- add 'crashdump' to shared_preload_libraries in postgresql.conf
- Start the server as normal
- Start psql and issue:
-- CREATE OR REPLACE FUNCTION crashdump_crashme() RETURNS void
AS '$libdir/crashdump','crashdump_crashme' LANGUAGE C;
-- SELECT crashdump_crashme();

Your backend should crash. In the error log (and, depending on how the
buffering works out, maybe in psql) you should see:

WARNING: loading dll
WARNING: loading dll try 1, 00000000
WARNING: loading dll try 2, 73880000
WARNING: pdump: 738C70D8
WARNING: Generating dumppath
WARNING: Generated dumppath
WARNING: dumping to path: crashdumps\backend.dmp
WARNING: outfile: 000000B0
WARNING: about to dump
NOTICE: crashdump: wrote crash dump to crashdumps\postgres-4341.mdmp

Once you have the dump file, you can fire up windbg from the Debugging
Tools for Windows and use File->Open Crash Dump to open it. The .excr
command will report what the exception that caused the crash was,
producing output like this:

> 0:000> .ecxr
> eax=00000000 ebx=00000000 ecx=02a1e290 edx=73831014 esi=02a1e188 edi=00c3f798
> eip=738313b2 esp=00c3f724 ebp=02a1e280 iopl=0 nv up ei pl zr na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
> crashdump!crashdump_crashme+0x2:
> 738313b2 c70001000000 mov dword ptr [eax],1 ds:0023:00000000=????????

and if possible opening the postgresql source file the crash happened in
to the appropriate line:

Datum
crashdump_crashme(PG_FUNCTION_ARGS)
{
int * ptr = NULL;
*ptr = 1; <--- highlighted
return NULL;
}

If you're using Visual Studio Professional (not the free Express
edition, unfortunately) you should also be able to debug the crash dump
that way. I don't have it to test with.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/