[postgis-devel] && leaks

[strk]

On Thu, Mar 11, 2004 at 01:35:00PM -0000, Mark Cave-Ayland wrote:
> Hi strk/Dave,
> 
> I've just had a quick look at ggeometry_consistent() and the GiST code,
> and it looks as if the GiST code will pfree() the gistentryinit()
> parameters for you. However it could be that memory leak strk's still
> seeing after applying Dave's && patch could be the result of the
> convert_box3d_to_box() being used in ggeometry_consistent() below:
> 
> 
> 	in = (GEOMETRY*)PG_DETOAST_DATUM( entry->key );
> 
> 	if (in->nobjs ==0)  // this is the EMPTY geometry
> 	{
> 		//elog(NOTICE,"found an empty geometry");
> 		// dont bother adding this to the index
> 		PG_RETURN_POINTER(entry);
> 	}
> 	else
> 	{
> 		r = convert_box3d_to_box(&in->bvol);
> 		if ( in != (GEOMETRY*)DatumGetPointer(entry->key) )
> 		{
> 			pfree( in );
> 		}
> 
> 		gistentryinit(*retval, PointerGetDatum(r), entry->rel,
> entry->page,
> 			entry->offset, sizeof(BOX), FALSE);
> 	}
> 
> 
> It doesn't look as if r is being pfree()d. strk, would applying Dave's
> fix to this call to convert_box3d_to_box() aswell solve the memory leak
> you are seeing?

Nope. It would make the backend die on segmentation fault.
It seems like it should not be our business to pfree() that,
as you observed earlier in this mail.

Please check yourself, since I'm working with PG-CVS and thus
could have seen a transient problem with pg code. I proceeded
as following: fill a file with create index / drop index calls,
connect to a backend, source that file, watch process size.
The 'leak' I've been seeing was very very small (4bytes each run?).

> Cheers,
> 
> Mark.

--strk;