From: | Duncan Rance <postgres(at)dunquino(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: BUG #6425: Bus error in slot_deform_tuple |
Date: | 2012-02-02 18:28:12 |
Message-ID: | B6B764C0-60A2-45E1-BE28-A9561487A4E4@dunquino.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 2 Feb 2012, at 18:02, Duncan Rance wrote:
>
> At last I have been able to reproduce this problem in a relatively simple (yet contrived) way.
Doh! Should have mentioned this already, but in case a Sparc is not available, the latest on the debugging is as follows:
As well as the bus error, I also saw the same symptom as described in BUG #6200. I changed the four places that did an elog ERROR "invalid memory alloc request size" to PANIC instead and got a raft of core files.
I have not dug any further as yet, but at the following function on the stack:
char *
text_to_cstring(const text *t)
The values t and tunpacked are the same, so pg_detoast_datum_packed() did not modify t. And len comes out as -4.
A couple of bits from dbx:
(dbx) print -fx t->vl_len_[0]
t->vl_len_[0] = 0xffffff84
(dbx) examine tunpacked /2x
0x0000010000ceb9dc: 0x8474 0x776f
Going to have a look further up the stack now.
Cheers,
Dunc
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-02-02 21:44:10 | Re: BUG #6425: Bus error in slot_deform_tuple |
Previous Message | Ashesh Vashi | 2012-02-02 18:02:10 | Re: BUG #6429: i cannot complete installation due to a forgotten password |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-02-02 19:02:05 | Re: spgist text_ops and LIKE |
Previous Message | Robert Haas | 2012-02-02 18:21:40 | Re: spgist text_ops and LIKE |