Thread: BUG #7597: exception 0xC0000005

The following bug has been logged on the website:

Bug reference:      7597
Logged by:          Bo T Jensen
Email address:      bo@budget123.dk
PostgreSQL version: 9.1.6
Operating system:   windows 7 home premium 64
Description:        =


Ive managed to boil this down to a repeatable example on a test setup, but
it was found originally on windows server 2008 (64 bit).

pg_log:
2012-10-11 11:29:49 CEST LOG:  server process (PID 4400) was terminated by
exception 0xC0000005
2012-10-11 11:29:49 CEST HINT:  See C include file "ntstatus.h" for a
description of the hexadecimal value.
2012-10-11 11:29:49 CEST LOG:  terminating any other active server
processes
2012-10-11 11:29:49 CEST WARNING:  terminating connection because of crash
of another server process
2012-10-11 11:29:49 CEST DETAIL:  The postmaster has commanded this server
process to roll back the current transaction and exit, because another
server process exited abnormally and possibly corrupted shared memory.
2012-10-11 11:29:49 CEST HINT:  In a moment you should be able to reconnect
to the database and repeat your command.
2012-10-11 11:29:49 CEST WARNING:  terminating connection because of crash
of another server process
2012-10-11 11:29:49 CEST DETAIL:  The postmaster has commanded this server
process to roll back the current transaction and exit, because another
server process exited abnormally and possibly corrupted shared memory.
2012-10-11 11:29:49 CEST HINT:  In a moment you should be able to reconnect
to the database and repeat your command.
2012-10-11 11:29:49 CEST LOG:  all server processes terminated;
reinitializing
2012-10-11 11:29:59 CEST FATAL:  pre-existing shared memory block is still
in use
2012-10-11 11:29:59 CEST HINT:  Check if there are any old server processes
still running, and terminate them.

Offending sql looks like this:
select 1 from reference
where username =3D 'user1'
and (refid, '127.0.0.1', 'manager1') not in (select refid, ip, manager from
loguser);

Kind regards
Bo T Jensen

Self-contained case attached.

On 10/11/2012 06:07 PM, Bo Thorbjørn Jensen wrote:
> Self-contained case attached.

No crash here on  version() = PostgreSQL 9.1.5 on
x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat
4.7.0-5), 64-bit

>

On 11.10.2012 14:42, Craig Ringer wrote:
> On 10/11/2012 06:07 PM, Bo Thorbj=C3=B8rn Jensen wrote:
>> Self-contained case attached.
>
> No crash here on version() =3D PostgreSQL 9.1.5 on
> x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat
> 4.7.0-5), 64-bit

I can reproduce this on my Windows box with the script Bo provided, with=20
a fresh checkout from git master branch. Stack trace looks like this:

.  0  Id: 92c.71c Suspend: 1 Teb: 000007ff`fffde000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`0053eb80 00000001`3f929a31 postgres!int8eq+0x12=20
[c:\postgresql\src\backend\utils\adt\int8.c @ 205]
00000000`0053ebb0 00000001`3f5321a0 postgres!FunctionCall2Coll+0xa1=20
[c:\postgresql\src\backend\utils\fmgr\fmgr.c @ 1326]
00000000`0053efb0 00000001`3f573bf3 postgres!execTuplesUnequal+0xe0=20
[c:\postgresql\src\backend\executor\execgrouping.c @ 168]
00000000`0053f020 00000001`3f572ad2 postgres!findPartialMatch+0xa3=20
[c:\postgresql\src\backend\executor\nodesubplan.c @ 592]
00000000`0053f090 00000001`3f57293b postgres!ExecHashSubPlan+0x172=20
[c:\postgresql\src\backend\executor\nodesubplan.c @ 156]
00000000`0053f0e0 00000001`3f541ccb postgres!ExecSubPlan+0xcb=20
[c:\postgresql\src\backend\executor\nodesubplan.c @ 79]
00000000`0053f120 00000001`3f545c89 postgres!ExecEvalNot+0x5b=20
[c:\postgresql\src\backend\executor\execqual.c @ 2670]
00000000`0053f170 00000001`3f54995b postgres!ExecQual+0x79=20
[c:\postgresql\src\backend\executor\execqual.c @ 5124]
00000000`0053f1d0 00000001`3f56fe71 postgres!ExecScan+0x1ab=20
[c:\postgresql\src\backend\executor\execscan.c @ 195]
00000000`0053f240 00000001`3f539034 postgres!ExecSeqScan+0x21=20
[c:\postgresql\src\backend\executor\nodeseqscan.c @ 116]
00000000`0053f270 00000001`3f535ca0 postgres!ExecProcNode+0x114=20
[c:\postgresql\src\backend\executor\execprocnode.c @ 399]
00000000`0053f2c0 00000001`3f533dda postgres!ExecutePlan+0x60=20
[c:\postgresql\src\backend\executor\execmain.c @ 1394]
00000000`0053f300 00000001`3f533bc5 postgres!standard_ExecutorRun+0x20a=20
[c:\postgresql\src\backend\executor\execmain.c @ 313]
00000000`0053f380 00000001`3f78fe80 postgres!ExecutorRun+0x45=20
[c:\postgresql\src\backend\executor\execmain.c @ 251]
00000000`0053f3b0 00000001`3f78facb postgres!PortalRunSelect+0x130=20
[c:\postgresql\src\backend\tcop\pquery.c @ 946]
00000000`0053f420 00000001`3f78a368 postgres!PortalRun+0x28b=20
[c:\postgresql\src\backend\tcop\pquery.c @ 789]
00000000`0053f5c0 00000001`3f789277 postgres!exec_simple_query+0x4b8=20
[c:\postgresql\src\backend\tcop\postgres.c @ 1061]
00000000`0053f700 00000001`3f707b70 postgres!PostgresMain+0x7c7=20
[c:\postgresql\src\backend\tcop\postgres.c @ 3978]
00000000`0053f900 00000001`3f7065ae postgres!BackendRun+0x270=20
[c:\postgresql\src\backend\postmaster\postmaster.c @ 3672]
00000000`0053f960 00000001`3f59cba9 postgres!SubPostmasterMain+0x2be=20
[c:\postgresql\src\backend\postmaster\postmaster.c @ 4174]

- Heikki

Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 11.10.2012 14:42, Craig Ringer wrote:
>> No crash here on version() = PostgreSQL 9.1.5 on
>> x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat
>> 4.7.0-5), 64-bit

> I can reproduce this on my Windows box with the script Bo provided, with
> a fresh checkout from git master branch. Stack trace looks like this:

I see it too.  I think the crash probably only occurs on a 32-bit build
(or one where you've disabled int8-pass-by-value anyway).  Looks like
something's confused about cross-data-type comparisons --- this is an
int4 vs int8 comparison, so it shouldn't be ending up at int8eq.

            regards, tom lane

I wrote:
> I see it too.  I think the crash probably only occurs on a 32-bit build
> (or one where you've disabled int8-pass-by-value anyway).  Looks like
> something's confused about cross-data-type comparisons --- this is an
> int4 vs int8 comparison, so it shouldn't be ending up at int8eq.

Argh ... the reason we're ending up at int8eq is that findPartialMatch
is using the wrong set of equality functions.  hashtable->cur_eq_funcs
correctly references int8eq, but what we want to be using is the
SubPlanState's cur_eq_funcs.  Amazing it took this long for anybody
to notice, because that's been wrong a long time.

            regards, tom lane