Re: Computer VARSIZE_ANY(PTR) during debugging
От | Amit Langote |
---|---|
Тема | Re: Computer VARSIZE_ANY(PTR) during debugging |
Дата | |
Msg-id | CA+HiwqGXCV8-xCaPMqKqqRaCpZ=BRxZ3RixiML+Y0AiXwn87yw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Computer VARSIZE_ANY(PTR) during debugging (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | 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 по дате отправления: