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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/geos-devel >>> >> >> _______________________________________________ >> geos-devel mailing list >> geos-devel@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/geos-devel >> > _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel