Re: BUG #6425: Bus error in slot_deform_tuple

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Duncan Rance <postgres(at)dunquino(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: BUG #6425: Bus error in slot_deform_tuple
Date: 2012-02-02 21:56:30
Message-ID: 5101.1328219790@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I wrote:
> So far no luck reproducing any issue with this test case.

And I swear my finger had barely left the "send" key when:

TRAP: FailedAssertion("!(((lpp)->lp_flags == 1))", File: "heapam.c", Line: 735)
LOG: server process (PID 24740) was terminated by signal 6: Aborted
DETAIL: Failed process was running: SELECT * FROM repro_02_ref;
LOG: terminating any other active server processes

So:

(1) no need to worry about GUC settings. It's just a shade less
probable than I'd supposed from your message.

(2) I suspect you are not running with asserts enabled. You might
have better luck isolating this if they were on.

I have not gotten very far with the coredump, except to observe that
gdb says the Assert ought to have passed:

(gdb) f 3
#3 0x0000000000475248 in heapgettup_pagemode (scan=0x1457b08,
dir=<optimized out>, nkeys=0, key=0x0) at heapam.c:735
735 Assert(ItemIdIsNormal(lpp));
(gdb) p lpp
$1 = (ItemIdData *) 0x7fea59705d90
(gdb) p *lpp
$2 = {lp_off = 7936, lp_flags = 1, lp_len = 34}

This suggests very strongly that indeed the buffer was changing under
us.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Steven Schlansker 2012-02-02 23:30:17 Re: [JDBC] BUG #6293: JDBC driver performance
Previous Message Tom Lane 2012-02-02 21:44:10 Re: BUG #6425: Bus error in slot_deform_tuple

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2012-02-02 23:00:41 Re: Patch pg_is_in_backup()
Previous Message Tom Lane 2012-02-02 21:44:10 Re: BUG #6425: Bus error in slot_deform_tuple