Re: BUG #5238: frequent signal 11 segfaults

From: Nagy Daniel <nagy(dot)daniel(at)telekom(dot)hu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5238: frequent signal 11 segfaults
Date: 2009-12-15 11:19:12
Message-ID: 4B2770B0.7040007@telekom.hu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I upgraded to 8.4.2, did a full reindex and vacuum (there were
no errors). But it segfaults as well:

Core was generated by `postgres: randir lovehunter 127.0.0.1(48268)
SELECT '.
Program terminated with signal 11, Segmentation fault.
[New process 7262]
#0 slot_deform_tuple (slot=0xc0d3b8, natts=20) at heaptuple.c:1130
1130 off = att_align_pointer(off, thisatt->attalign, -1,
(gdb) bt
#0 slot_deform_tuple (slot=0xc0d3b8, natts=20) at heaptuple.c:1130
#1 0x0000000000453b9a in slot_getattr (slot=0xc0d3b8, attnum=20,
isnull=0x7fffe48130af "") at heaptuple.c:1253
#2 0x000000000054418c in ExecEvalNot (notclause=<value optimized out>,
econtext=0x1dda4503, isNull=0x7fffe48130af "",
isDone=<value optimized out>) at execQual.c:2420
#3 0x000000000054466b in ExecQual (qual=<value optimized out>,
econtext=0xc17000, resultForNull=0 '\0') at execQual.c:4909
#4 0x000000000054ae55 in ExecScan (node=0xc16ef0, accessMtd=0x550b80
<BitmapHeapNext>) at execScan.c:131
#5 0x0000000000543da0 in ExecProcNode (node=0xc16ef0) at execProcnode.c:373
#6 0x0000000000553516 in ExecHashJoin (node=0xc15dd0) at nodeHashjoin.c:598
#7 0x0000000000543de8 in ExecProcNode (node=0xc15dd0) at execProcnode.c:412
#8 0x0000000000556367 in ExecNestLoop (node=0xc14cc0) at nodeNestloop.c:120
#9 0x0000000000543e18 in ExecProcNode (node=0xc14cc0) at execProcnode.c:404
#10 0x0000000000556367 in ExecNestLoop (node=0xc12ee0) at nodeNestloop.c:120
#11 0x0000000000543e18 in ExecProcNode (node=0xc12ee0) at execProcnode.c:404
#12 0x0000000000556367 in ExecNestLoop (node=0xc110e0) at nodeNestloop.c:120
#13 0x0000000000543e18 in ExecProcNode (node=0xc110e0) at execProcnode.c:404
#14 0x0000000000557cc1 in ExecSort (node=0xc0eec0) at nodeSort.c:102
#15 0x0000000000543d10 in ExecProcNode (node=0xc0eec0) at execProcnode.c:423
#16 0x00000000005418b2 in standard_ExecutorRun (queryDesc=0xbb95e0,
direction=ForwardScanDirection, count=0) at execMain.c:1504
#17 0x00000000005ed687 in PortalRunSelect (portal=0xbf7000,
forward=<value optimized out>, count=0, dest=0x7f863746adb8)
at pquery.c:953
#18 0x00000000005eea39 in PortalRun (portal=0xbf7000,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x7f863746adb8,
altdest=0x7f863746adb8, completionTag=0x7fffe4813650 "") at pquery.c:779
#19 0x00000000005e9e07 in exec_simple_query (
query_string=0xb82e10 "SELECT * FROM valogatas WHERE uid!='64708'
AND eletkor BETWEEN 40 AND 52 AND megyeid='9' AND keresettnem='t' AND
dom='iwiw.hu' AND appid='2001434963' AND nem='f' ORDER BY random()
DESC") at postgres.c:991
#20 0x00000000005eb3d7 in PostgresMain (argc=4, argv=<value optimized
out>, username=0xacfe90 "randir") at postgres.c:3614
#21 0x00000000005bfe18 in ServerLoop () at postmaster.c:3449
#22 0x00000000005c0ba7 in PostmasterMain (argc=5, argv=0xacaa90) at
postmaster.c:1040
#23 0x000000000056a568 in main (argc=5, argv=0xacaa90) at main.c:188

(gdb) p (char *) debug_query_string
$1 = 0xb82e10 "SELECT * FROM valogatas WHERE uid!='64708' AND eletkor
BETWEEN 40 AND 52 AND megyeid='9' AND keresettnem='t' AND dom='iwiw.hu'
AND appid='2001434963' AND nem='f' ORDER BY random() DESC"

When I run this query manually, it works.

Regards,

Daniel

Tom Lane wrote:
> Nagy Daniel <nagy(dot)daniel(at)telekom(dot)hu> writes:
>> I have pg segfaults on two boxes, a DL160G6 and a DL380g5.
>> I've just checked their memory with memtest86+ v2.11
>> No errors were detected.
>> We also monitor the boxes via IPMI, and there are no signs
>> of HW failures.
>
> Hm. Well, now that 8.4.2 is out, the first thing you ought to do is
> update and see if this happens to be resolved by any of the recent
> fixes. (I'm not too optimistic about that, because it doesn't look
> exactly like any of the known symptoms, but an update is certainly
> worth your time in any case.)
>
> If you still see it after that, please try to extract a reproducible
> test case.
>
> regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2009-12-15 12:15:36 Re: BUG #5240: Stable Functions that return a table type with a dropped column fail
Previous Message Craig Ringer 2009-12-15 05:09:27 Re: statement_timeout is not cancelling query