problem with varlena and extended type

Started by Pavel Stehulealmost 17 years ago5 messageshackers
Jump to latest
#1Pavel Stehule
pavel.stehule@gmail.com

Hello,

I can't to find reason of my problem. I have a varlena type. This type
works well with plain storage, but this raise some random exception
with extended storage. It finish on Assert((data - start) ==
data_size)[heaptuple.c]; I checked - when I return varlena from in
function, then it has correct size, but in this function VARSIZE
returns different value.

some log
NOTICE: KOKES SIZE 36242, pointer: 149948300 -- varlena check
NOTICE: heap_fill_tuple [size: 36250, bits -1, tupleesc: 150141444, attrs: 3
NOTICE: iteration 0
NOTICE: >>> attbyval 1, attlen 4
NOTICE: [data: 150208808d, data length: 4]
NOTICE: iteration 1
NOTICE: >>> attbyval 1, attlen 4
NOTICE: [data: 150208812d, data length: 4]
NOTICE: iteration 2
NOTICE: >>> attbyval 0, attlen -1
NOTICE: FULL VARLENA 149948300 <36242> -- correct size in heap_fill_tuple

but
NOTICE: KOKES SIZE 55966, pointer: 150029636, -- varlena size
NOTICE: heap_fill_tuple [size: 55974, bits -1, tupleesc: 149930464, attrs: 3
NOTICE: iteration 0
NOTICE: >>> attbyval 1, attlen 4
NOTICE: [data: 150029680d, data length: 4]
NOTICE: iteration 1
NOTICE: >>> attbyval 1, attlen 4
NOTICE: [data: 150029684d, data length: 4]
NOTICE: iteration 2
NOTICE: >>> attbyval 0, attlen -1
NOTICE: FULL VARLENA 150029636 <13999> -- wrong size, why?
NOTICE: 14007 [55974]
psql83:/home/pavel/src/postgresql-8.3.7/contrib/kokes/objerr1.sql:4:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

any idea, why size of varlena is broken?

thank you
Pavel Stehule

p.s. I use macros SET_VARSIZE and VARSIZE

define DatumGetKokesData(x)<-->((KokesData*)DatumGetPointer(x))
#define PG_GETARG_KokesData(x)<>DatumGetKokesData(
PG_DETOAST_DATUM(PG_GETARG_DATUM(x)) )
#define PG_RETURN_KokesData(x)<>PG_RETURN_POINTER(x)

#2Bruce Momjian
bruce@momjian.us
In reply to: Pavel Stehule (#1)
Re: problem with varlena and extended type

It's pretty hard to guess where your bug is sitting here with no code
and no idea even what you've done to trigger it.

At a guess there someplace you haven't detoasted a datum that had to
be detoasted. But like I said that's just a guess.

#3Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#2)
Re: problem with varlena and extended type

On Sat, Jul 4, 2009 at 10:31 PM, Greg Stark<gsstark@mit.edu> wrote:

It's pretty hard to guess where your bug is sitting here with no code
and no idea even what you've done to trigger it.

At a guess there someplace you haven't detoasted a datum that had to
be detoasted. But like I said that's just a guess.

Actually on further thought I think this smells like a memory
management bug. Maybe you've either you've prematurely freed this data
structure or realloc'd it without tracking the new pointer and have
returned a pointer to the freed object.

--
greg
http://mit.edu/~gsstark/resume.pdf

#4Pavel Stehule
pavel.stehule@gmail.com
In reply to: Bruce Momjian (#3)
Re: problem with varlena and extended type

2009/7/4 Greg Stark <gsstark@mit.edu>:

On Sat, Jul 4, 2009 at 10:31 PM, Greg Stark<gsstark@mit.edu> wrote:

It's pretty hard to guess where your bug is sitting here with no code
and no idea even what you've done to trigger it.

see attachment - sorry, comments are czech

At a guess there someplace you haven't detoasted a datum that had to
be detoasted. But like I said that's just a guess.

I have a problem with "in" function. So I have not a control over
process. I return a varlena value, that's all.

Actually on further thought I think this smells like a memory
management bug. Maybe you've either you've prematurely freed this data
structure or realloc'd it without tracking the new pointer and have
returned a pointer to the freed object.

I'll look on it. It looks strange. I don't use pfree. 2x or 3x use repalloc.

regards
Pavel Stehule

Show quoted text

--
greg
http://mit.edu/~gsstark/resume.pdf

Attachments:

kokes.ctext/plain; charset=US-ASCII; name=kokes.cDownload
kokes.htext/plain; charset=UTF-8; name=kokes.hDownload
parse.yapplication/octet-stream; name=parse.yDownload
#5Pavel Stehule
pavel.stehule@gmail.com
In reply to: Bruce Momjian (#3)
Re: problem with varlena and extended type

2009/7/4 Greg Stark <gsstark@mit.edu>:

On Sat, Jul 4, 2009 at 10:31 PM, Greg Stark<gsstark@mit.edu> wrote:

It's pretty hard to guess where your bug is sitting here with no code
and no idea even what you've done to trigger it.

At a guess there someplace you haven't detoasted a datum that had to
be detoasted. But like I said that's just a guess.

Actually on further thought I think this smells like a memory
management bug. Maybe you've either you've prematurely freed this data
structure or realloc'd it without tracking the new pointer and have
returned a pointer to the freed object.

good shot - I had problem with repalloc

thank you very much
Pavel

Show quoted text

--
greg
http://mit.edu/~gsstark/resume.pdf