[geos-devel] An Immodest Proposal

[Paul Ramsey]

Crisis averted, situation normal.
The problem was in the memory contexted being switch out from under
the allocator. The difficulty is that palloc() isn't a function in
pgsql, it's rewritten to a two-parameter memory context allocation,
and putting that function into the callback makes the question of
"which context am I addressing?" a bit hard to figure out. If I use a
static context like TopMemoryContext things work, but that means I'm
leaking into a permanent pool which is non-optimal. More work to do...
:)

P.

On Tue, Sep 30, 2008 at 5:38 PM, Chris Hodgson <chodgson at refractions.net> wrote:
> Do all of the "new std:vector<Geometry *>" calls use the overridden new?
>
> If not, then I think the problem is that the code inside the extern C{}
> doesn't understand that we have overridden new and delete. It MIGHT be as
> easy (and clumsy) as adding two methods geosNew and geosDelete, outside of
> the extern C {} block (which in turn call the overridden new and delete),
> and calling those from within the extern C{} instead of calling the raw
> new/delete which we are overridden.
>
> I would try this myself except I don't have the development environment
> setup yet...
>
> Chris
>
> Paul Ramsey 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.
>>
>>
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>