On Mon, Nov 05, 2012 at 09:10:30AM -0500, Matthew Gerber wrote:
> On Sun, Nov 4, 2012 at 3:39 AM, Craig Ringer <ringerc@ringerc.id.au> wrote:
> > On 11/04/2012 08:47 AM, Matthew Gerber wrote:
> > So I attached the VS debugger, but the server died without raising an
> > exception in VS. Not sure what's going on here.
Not sure either. I attached WinDbg to a client backend and directed that
backend to call a function written to trigger the same exception. It caught
the exception and reported a credible stack trace. I get the same outcome
using Visual Studio Express 2012 for Windows Desktop.
> >> Try creating a directory called "crashdumps" in the data directory, at
> > the same level as "pg_xlog" and "pg_clog" etc. Give the "postgresql" user
> > the "full control" permission on it. Then run the test again.
> >
> > Do any minidump files appear in the directory? If so, you can examine them
> > with windbg or Visual Studio to see where the crash happened.
>
> I did this but nothing appears in crashdumps after the server crashes. The
> latest test I did included the addition of this directory and the disabling
> of my antivirus software. Nothing seems to have changed. Following Tom's
> suggestion, I'll try to get a stack trace again (last time didn't produce
> anything).
I now see that this exception cannot yield a minidump; the CRT restores the
default handler before raising it. Since this exception is intended to avert
a security exposure, perhaps Microsoft reasoned that allowing application code
to regain control would dilute that benefit. That choice is certainly
inconvenient for us, though.
> The only other thing I've noticed is that the crash always occurs when
> inserting into the "places" table (definition in previous email), even
> though there are two other tables that are also receiving inserts. This is
> odd to me. Any thoughts?
That's not intrinsically surprising unless, say, the tables have the same
structure and receive the same data.
Thanks,
nm
