Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group