[geos-devel] An Immodest Proposal

[Paul Ramsey]

Help!

I've attached the modified geos_c.cpp and geos_c.h.in files for geos
for your perusal. The symptom is this:

- Modified containsPrepared to use initGEOSMemory
- Run an ST_Contains(g,g,i) prepared example
- Memory is both allocated and deallocated through the over-ridden
functions just fine
- UNTIL
- The code gets to the point where it has to deallocate a prepared
geometry and runs GEOSPreparedGeom_destroy()
- At that point, the deallocation does *not* enter the over-ridden
new/delete operators, it appears to use default operators, and
everything goes boom

So,

- the over-ride of new/delete seems to work fine inside the main geos
library, things get both allocated and freed using palloc and pfree
- but the delete inside the "extern C {}" block where
GEOSPreparedGeom_destroy does *not* appear to be over-ridden by our
cunning trick

Anyone have the secret sauce?

P.

On Tue, Sep 30, 2008 at 10:36 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Time to try this in "real life" with PostgreSQL and palloc/pfree.  I'm
> going to create GEOS and PostGIS experimental branches, and commit my
> work there, so that folks with other platforms can try it out.
>
> On Tue, Sep 30, 2008 at 9:55 AM, Chris Hodgson <chodgson at refractions.net> wrote:
>> Very nice Paul.
>>
>> Those two std allocs are a bit scary... I had a feeling we might have some
>> of those, and they seem worse than I had initially thought. The problem is
>> that either they are attempted to be freed, using the provided free function
>> - and who knows what error that could bring - or they are not, and we're
>> leaking. If they are only created once at load of the DLL and never actually
>> freed, but simply go away when the DLL is unloaded, then I guess we're ok.
>> But it seems likely to me that the C++ runtime would be trying to free them
>> using your own provided free function... can we do a test where we provide
>> pfree and see what it does with that? ie. if you try to pfree() a regularly
>> malloc()'d segment of memory, does it actually free it without raising any
>> errors?
>>
>> It would be really nice to know what those things that are getting created
>> earlier are, too...
>> but I guess it all just comes down to, does it work in postgres and not
>> leak?
>>
>> Chris
>>
>> Paul Ramsey wrote:
>>>
>>> It turns out it is a quite small modification, and works pretty well:
>>>
>>> http://trac.osgeo.org/geos/attachment/ticket/208/memdiff.patch
>>>
>>> My patch adds the ability to override, and also has some printfs to
>>> show what is happening. When the overridden allocator is called
>>> without the runtime callback set, it prints "std alloc" and when it's
>>> called with the callback set, it prints "geos alloc".
>>>
>>> Here's a little program that exercises it:
>>>
>>> #include <stdio.h>
>>> #include "/usr/local/include/geos_c.h"
>>> #include <stdlib.h>
>>>
>>> int main() {
>>>  printf("main\n");
>>>
>>>  GEOSCoordSequence* cs;
>>>  GEOSGeometry* g;
>>>  int r;
>>>
>>>  printf("initgeos\n");
>>>  initGEOSMemory(malloc, free);
>>>  printf("coordseqcreate\n");
>>>  cs = GEOSCoordSeq_create(1, 2);
>>>  printf("coordseqsetx\n");
>>>  r = GEOSCoordSeq_setX(cs, 0, 1.0);
>>>  printf("coordseqsety\n");
>>>  r = GEOSCoordSeq_setY(cs, 0, 1.0);
>>>  printf("createpoint\n");
>>>  g = GEOSGeom_createPoint(cs);
>>>
>>>  return 0;
>>>
>>> }
>>>
>>>
>>> And here is the output:
>>>
>>> Heron:tmp pramsey$ ./a.out
>>> std alloc!
>>> std alloc!
>>> main
>>> initgeos
>>> coordseqcreate
>>> geos alloc!
>>> geos alloc!
>>> geos alloc!
>>> coordseqsetx
>>> coordseqsety
>>> createpoint
>>> geos alloc!
>>>
>>> So, something in C++ is doing a couple allocations before we can slip
>>> in and get our other function in place. But we can get all the big
>>> stuff caught no problem.
>>>
>>> P.
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>