Re: Unresolved error 0xC0000409 on Windows Server

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

In response to

Responses

Browse pgsql-hackers by date

  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