From: | Matthew Gerber <gerber(dot)matthew(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unresolved error 0xC0000409 on Windows Server |
Date: | 2012-12-09 19:09:21 |
Message-ID: | CAOcpbfoWKo0mvBqvC5oAV2a9-P+exa79=OLOSC0p5NQTS1Fosw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)matthew(at)gmail(dot)com>wrote:
>
>
> On Sun, Nov 11, 2012 at 8:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Noah Misch <noah(at)leadboat(dot)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 | Content-Type | Size |
---|---|---|
server_crash.sql | application/octet-stream | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-12-09 19:14:50 | Re: logical changeset generation v3 - git repository |
Previous Message | Andres Freund | 2012-12-09 19:05:32 | Re: xlogreader v3/xlogdump v2 |