Re: Computer VARSIZE_ANY(PTR) during debugging - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Computer VARSIZE_ANY(PTR) during debugging
Date
Msg-id CA+HiwqGXCV8-xCaPMqKqqRaCpZ=BRxZ3RixiML+Y0AiXwn87yw@mail.gmail.com
Whole thread Raw
In response to Re: Computer VARSIZE_ANY(PTR) during debugging  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Thu, Jun 27, 2013 at 12:02 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Amit Langote escribió:
>
>> The segfault in question happens at line 1141:
>>
>> off = att_align_pointer(off, thisatt->attalign, -1, tp + off);
>>
>> char       *tp;                         /* ptr to tuple data */
>> long        off;                    /* offset in tuple data */
>>
>> Disassembling seems to suggest (tp + off) is the faulting address.
>> Apparently, the segfault happens when 5th text column is being
>> extracted from a tuple (char(n), char(n), int4, char(n), text, ...).
>> Since, tp is fixed for the whole duration of loop and only off is
>> subject to change over iterations, it may have happened due to wrong
>> offset in this iteration.
>>
>> Has anything of this kind been encountered/reported before?
>
> Yes, I vaguely recall I have seen this in cases where tuples contain
> corrupt data.  I think you just need the length word of the fourth datum
> to be wrong.
>

The query in question is:

select col1, col2, col4, octet_length(col5) from table where
octet_length(col5) > 8000000;

In case of corrupt data, even select * from table should give
segfault, shouldn't it?

--
Amit Langote



pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: A better way than tweaking NTUP_PER_BUCKET
Next
From: Tom Lane
Date:
Subject: Re: PQConnectPoll, connect(2), EWOULDBLOCK and somaxconn