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

From Amit Langote
Subject Computer VARSIZE_ANY(PTR) during debugging
Date
Msg-id CA+HiwqGgD8HgbyBuoC1yQ36B2AB0mS8c_nJLu7WBXiaR1--3mg@mail.gmail.com
Whole thread Raw
Responses Re: Computer VARSIZE_ANY(PTR) during debugging  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Computer VARSIZE_ANY(PTR) during debugging  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Hello,

Is it possible to compute VARSIZE_ANY(PTR) during debugging?

---------------------------------------------------------
#define VARSIZE_ANY(PTR) \       (VARATT_IS_1B_E(PTR) ? VARSIZE_1B_E(PTR) : \        (VARATT_IS_1B(PTR) ?
VARSIZE_1B(PTR): \         VARSIZE_4B(PTR)))
 

#define VARATT_IS_1B_E(PTR) \       ((((varattrib_1b *) (PTR))->va_header) == 0x80)
-----------------------------------------------------------

I tried using above expression, but it gives following:

(gdb) p ((((varattrib_1b *) ( tp+off ))->va_header) == 0x80)
No symbol "varattrib_1b" in current context.

Am I missing some gdb technique here using which I could find value of
this expression?

By the way, I am trying to find cause of a segmentation fault using a
core dump which occurred in slot_deform_tuple() of heaptuple.c in
8.4.2 (excuse me, but if this is unheard off, maybe there is an
issue). 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?


--
Amit Langote



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: updated emacs configuration
Next
From: Amit Kapila
Date:
Subject: Re: Patch for fail-back without fresh backup