Re: Computer VARSIZE_ANY(PTR) during debugging

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Computer VARSIZE_ANY(PTR) during debugging
Date: 2013-06-27 00:44:15
Message-ID: CA+HiwqHL0inSto6SWTqmq5fSqhGqThXZh+NJEP5+rGSOz_2ygg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 27, 2013 at 12:02 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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.
>

I want to find exactly that. Is there any way to get that value?
AFAIU, a tuple would not contain all of the data of individual
attributes; some might be TOAST'd, but is the total length (including
TOAST'd part) added to offset (in 'tp + offset') to point to the next
attribute in the tuple?

Looking at the attlen == -1 value in tupDescriptor of the
ResultTupleSlot, VARSIZE_ANY() is used to calculate the length and
added to offset, but I find no way to calculate that while I am
dubugging.

--
Amit Langote

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-06-27 01:34:37 Re: [PATCH] Revive line type
Previous Message Noah Misch 2013-06-27 00:41:30 Re: Possible bug in CASE evaluation