problem with varlena and extended type

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)

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.

On Sat, Jul 4, 2009 at 10:31 PM, Greg Stark<gsstark(at)mit(dot)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

2009/7/4 Greg Stark <gsstark(at)mit(dot)edu>:
> On Sat, Jul 4, 2009 at 10:31 PM, Greg Stark<gsstark(at)mit(dot)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

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

2009/7/4 Greg Stark <gsstark(at)mit(dot)edu>:
> On Sat, Jul 4, 2009 at 10:31 PM, Greg Stark<gsstark(at)mit(dot)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

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