Обсуждение: 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 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)
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@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
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 >
Вложения
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 >