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

On 17/12/2010 3:46 PM, Magnus Hagander wrote:
>
> On Dec 17, 2010 8:02 AM, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au
> <mailto:craig(at)postnewspapers(dot)com(dot)au>> wrote:
> >
> > On 16/12/10 21:01, Magnus Hagander wrote:
> >
> > > Found another problem in it: when running with an older version of
> > > dbghelp.dll (which I was), it simply didn't work. We need to grab the
> > > version of dbghelp.dll at runtime and pick which things we're going to
> > > dump based on that.
> >
> > I was about to suggest dropping the fallback loading of the system
> > dbghelp.dll, and just bundle a suitable version with Pg, then I saw how
> > big the DLL is. It's 800kb (!!) of code that'll hopefully never get used
> > on any given system. With a footprint like that, bundling it seems
> > rather less attractive.
> >
> > I think Magnus is right: test the dbghelp.dll version and fall back to
> > supported features - as far back as XP, anyway; who cares about anything
> > earlier than that. An updated version can always be put in place by the
> > user if the built-in one can't produce enough detail.
>
> Did you get a chance to test that it still produced a full dump on your
> system?

I've just tested that and it looks ok so far. The dumps produced are
smaller - 1.3MB instead of ~4MB for a dump produced by calling a simple
"crashme()" function from SQL, the source for which follows at the end
of this post. However, I'm getting reasonable stack traces, as shown by
the windb.exe output below.

That said, the dump appears to exclude the backend's private memory. I
can't resolve *fcinfo from PG_FUNCTION_ARGS; it looks like the direct
values of arguments are available as they're on the stack, as are
function local variables, but the process heap isn't dumped so you can't
see the contents of any pointers-to-struct. That'll make it harder to
track down many kinds of error - but, on the other hand, means that
dumps of processes with huge work_mem etc won't be massively bloated.

That might be a safer starting point than including the private process
memory, really. I'd like to offer a flag to turn on dumping of private
process memory but I'm not sure how best to go about it, given that we'd
want to avoid accessing GUCs etc if possible. "later", I think; this is
better for now.

I'm happy with the patch as it stands, with the one exception that
consideration of mingw is required before it can be committed.

> Symbol search path is: C:\Users\Craig\Developer\postgres\Release\postgres;SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols;C:\Program Files\PostgreSQL\9.0\symbols
> Executable search path is:
> Windows 7 Version 7600 MP (2 procs) Free x86 compatible
> Product: WinNt, suite: SingleUserTS
> Machine Name:
> Debug session time: Fri Dec 17 17:37:19.000 2010 (UTC + 8:00)
> System Uptime: not available
> Process Uptime: 0 days 0:01:09.000
> ................................
> This dump file has an exception of interest stored in it.
> The stored exception information can be accessed via .ecxr.
> (16b4.cd8): Access violation - code c0000005 (first/second chance not available)
> eax=000002e8 ebx=03210aa8 ecx=0055e700 edx=03210a68 esi=03210a68 edi=0055ea14
> eip=771464f4 esp=0055e6d4 ebp=0055e6e4 iopl=0 nv up ei pl zr na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
> ntdll!KiFastSystemCallRet:
> 771464f4 c3 ret
> 0:000> .ecxr
> eax=00000000 ebx=00000000 ecx=0103fa88 edx=7001100f esi=0103fa78 edi=0103fab4
> eip=70011052 esp=0055f62c ebp=0103fa78 iopl=0 nv up ei pl zr na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
> crashme!crashdump_crashme+0x2:
> 70011052 c70001000000 mov dword ptr [eax],1 ds:0023:00000000=????????
> 0:000> ~
> . 0 Id: 16b4.cd8 Suspend: 0 Teb: 7ffdf000 Unfrozen
> 1 Id: 16b4.1798 Suspend: 0 Teb: 7ffde000 Unfrozen
> 2 Id: 16b4.6f4 Suspend: 0 Teb: 7ffdd000 Unfrozen
> 0:000> k
> *** Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr
> 0055f628 0142c797 crashme!crashdump_crashme+0x2 [c:\users\craig\developer\postgres\contrib\crashme\crashme.c @ 14]
> 0055f68c 0142c804 postgres!ExecMakeFunctionResult+0x427 [c:\users\craig\developer\postgres\src\backend\executor\execqual.c @ 1824]
> 0055f6b4 0142b760 postgres!ExecEvalFunc+0x34 [c:\users\craig\developer\postgres\src\backend\executor\execqual.c @ 2260]
> 0055f6e0 0142ba83 postgres!ExecTargetList+0x70 [c:\users\craig\developer\postgres\src\backend\executor\execqual.c @ 5095]
> 0055f720 0143f074 postgres!ExecProject+0x173 [c:\users\craig\developer\postgres\src\backend\executor\execqual.c @ 5312]
> 0055f734 01427e07 postgres!ExecResult+0x94 [c:\users\craig\developer\postgres\src\backend\executor\noderesult.c @ 157]
> 0055f744 01425ccd postgres!ExecProcNode+0x67 [c:\users\craig\developer\postgres\src\backend\executor\execprocnode.c @ 361]
> 0055f758 01426ace postgres!ExecutePlan+0x2d [c:\users\craig\developer\postgres\src\backend\executor\execmain.c @ 1236]
> 0055f788 0152ec7d postgres!standard_ExecutorRun+0x8e [c:\users\craig\developer\postgres\src\backend\executor\execmain.c @ 288]
> 0055f7ac 0152f290 postgres!PortalRunSelect+0x6d [c:\users\craig\developer\postgres\src\backend\tcop\pquery.c @ 953]
> 0055f834 0152c2b2 postgres!PortalRun+0x190 [c:\users\craig\developer\postgres\src\backend\tcop\pquery.c @ 803]
> 0055f8e8 0152cbe5 postgres!exec_simple_query+0x3a2 [c:\users\craig\developer\postgres\src\backend\tcop\postgres.c @ 1067]
> 0055f96c 014f2bfc postgres!PostgresMain+0x575 [c:\users\craig\developer\postgres\src\backend\tcop\postgres.c @ 3935]
> 0055f98c 014f58c9 postgres!BackendRun+0x19c [c:\users\craig\developer\postgres\src\backend\postmaster\postmaster.c @ 3562]
> 0055fb30 014575bc postgres!SubPostmasterMain+0x2f9 [c:\users\craig\developer\postgres\src\backend\postmaster\postmaster.c @ 4058]
> 0055fb48 0162847d postgres!main+0x1ec [c:\users\craig\developer\postgres\src\backend\main\main.c @ 173]
> 0055fb8c 76ab1194 postgres!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
> 0055fb98 7715b495 kernel32!BaseThreadInitThunk+0xe
> 0055fbd8 7715b468 ntdll!__RtlUserThreadStart+0x70
> 0055fbf0 00000000 ntdll!_RtlUserThreadStart+0x1b

/* Condensed source for crash-test contrib module. */
#include "postgres.h"
#include "fmgr.h"
PG_MODULE_MAGIC;
extern Datum crashdump_crashme(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(crashdump_crashme);
Datum
crashdump_crashme(PG_FUNCTION_ARGS)
{
int * ptr = NULL;
*ptr = 1;
return NULL;
}

--
Craig Ringer

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