[postgis-devel] Re: [geos-devel] An Immodest Proposal

[Paul Ramsey]

With attachments...

On Tue, Sep 30, 2008 at 4:47 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 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
>>>
>>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: geos_c.cpp
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080930/ece634c8/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geos_c.h.in
Type: application/octet-stream
Size: 18215 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080930/ece634c8/attachment.obj>