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

Paul Ramsey pramsey at cleverelephant.ca
Tue Sep 30 10:36:45 PDT 2008


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
>



More information about the postgis-devel mailing list