Re: Unresolved error 0xC0000409 on Windows Server - Mailing list pgsql-hackers

From Matthew Gerber
Subject Re: Unresolved error 0xC0000409 on Windows Server
Date
Msg-id CAOcpbfoWKo0mvBqvC5oAV2a9-P+exa79=OLOSC0p5NQTS1Fosw@mail.gmail.com
Whole thread Raw
In response to Re: Unresolved error 0xC0000409 on Windows Server  (Matthew Gerber <gerber.matthew@gmail.com>)
Responses Re: Unresolved error 0xC0000409 on Windows Server
List pgsql-hackers
All,

I have successfully isolated this error and created a simple SQL script to reproduce it. Just to recap - this script will cause a server crash with exception 0xC0000409 as described in previous emails. The crux of the problem seems to be my creation / use of the function st_transform_null. My intent with this function is to wrap the st_transform function provided by PostGIS, but account for the situation where the argument to be transformed is NULL. In this situation, st_transform throws an internal_error, which my function catches and returns NULL for. The error / crash is not caused by a NULL argument; rather, it is caused by the final value in the attached script's INSERT statement, which contains a lat/lon pair that is beyond PostGIS's range. I'm not questioning whether this value is actually outside the legal range, but I do not think such an input should cause the server to crash completely.

Here are the steps to reproduce the crash:

1) Create a new instance of a 9.2 server (Windows 64-bit), and a new database (call it test) with the PostGIS extension.

2) Run the script:

psql -U postgres -d test -f C:\server_crash.sql

You should see the following:

psql:C:/server_crash.sql:31: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
psql:C:/server_crash.sql:31: connection to server was lost


3) Check your log for the error.

I hope this helps. It took me quite a while to track down the problem so I hope someone can figure out what is going on under the hood. It seems to be a pretty significant problem.

Cheers,
Matt

On Sun, Nov 11, 2012 at 9:45 PM, Matthew Gerber <gerber.matthew@gmail.com> wrote:


On Sun, Nov 11, 2012 at 8:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Noah Misch <noah@leadboat.com> writes:
> So, I can reproduce the lower threshold, but the exception type does not agree
> with the one Matthew observed.

I finally got around to looking at the link you provided about error
0xC0000409, and realized that I'd been completely confusing it with
stack overflow --- but actually, it's a report that something scribbled
past the end of a finite-size local-variable array.  So I now think that
Matthew's stumbled across two completely independent bugs, and we've
fixed only one of them.  The 0xC0000409 error is something else, and
possibly a lot worse since it could conceivably be a security issue.

It still seems likely that the actual location of the bug is either
in PostGIS or in the GIST index code, but without the ability to
reproduce the failure it's awfully hard to find it.  Matthew, could
you try a bit harder to find a self-contained test case that produces
that error?

                        regards, tom lane

Sure, it might take me a while to find time but I'll keep it on my list.

Matt


Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: xlogreader v3/xlogdump v2
Next
From: Andres Freund
Date:
Subject: Re: logical changeset generation v3 - git repository