Thread: problem with varlena and extended type

problem with varlena and extended type

From
Pavel Stehule
Date:
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 logNOTICE:  KOKES SIZE 36242, pointer: 149948300 -- varlena checkNOTICE:  heap_fill_tuple [size: 36250, bits -1,
tupleesc:150141444, attrs: 3NOTICE:  iteration 0NOTICE:  >>> attbyval 1, attlen 4NOTICE:  [data: 150208808d, data
length:4]NOTICE:  iteration 1NOTICE:  >>> attbyval 1, attlen 4NOTICE:  [data: 150208812d, data length: 4]NOTICE:
iteration2NOTICE:  >>> attbyval 0, attlen -1NOTICE:  FULL VARLENA 149948300 <36242> -- correct size in heap_fill_tuple
 

butNOTICE:  KOKES SIZE 55966, pointer: 150029636, -- varlena sizeNOTICE:  heap_fill_tuple [size: 55974, bits -1,
tupleesc:149930464, attrs: 3NOTICE:  iteration 0NOTICE:  >>> attbyval 1, attlen 4NOTICE:  [data: 150029680d, data
length:4]NOTICE:  iteration 1NOTICE:  >>> attbyval 1, attlen 4NOTICE:  [data: 150029684d, data length: 4]NOTICE:
iteration2NOTICE:  >>> attbyval 0, attlen -1NOTICE:  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 unexpectedlyThis probably means the server terminated abnormallybefore or while processing
therequest.
 

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)


Re: problem with varlena and extended type

From
Greg Stark
Date:
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.


Re: problem with varlena and extended type

From
Greg Stark
Date:
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


Re: problem with varlena and extended type

From
Pavel Stehule
Date:
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

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

Attachment

Re: problem with varlena and extended type

From
Pavel Stehule
Date:
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

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