[geos-devel] An Immodest Proposal

[Paul Ramsey]

So, moving the instantiation of geomFactory object into initGEOS did
nothing for me, the object is still allocated by malloc, not palloc,
perhaps because it's a global, so it's getting set up at library load
time?

Putting the whole factory and creation process inside the function
bodies could get very expensive, since the functions are called
repetitively a lot, which means each call would do a newfactory,
newgeo, destroygeom, destroyfactory (ack!).  This is presumably why
the factory was made into a global outside the functions.

I'm at an impasse. If new/delete are overridden, when the end of a
postgres comes along, the system will attempt to pfree the globals as
it cleans up the library, and since the globals are malloc'ed,
segfault ensues.

If we backtrack to not over-riding new/delete, then we have the
problem of leaking the prepared objects at the end of each
transaction.

P.

On Wed, Oct 1, 2008 at 11:08 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> So, using a longer lived memory context I can get right to the end of
> a query before the segfault arrives. The segfault happens when
> deleting a geometryfactory at the end, which tells me a couple things,
> I think.
>
> First, those two std allocs that sneak in before we over-ride new are
> related to the geometry factory. The segfault happens when we're
> trying to pfree the geometryfactory.
>
> The offending code is this in geos_c.cpp:
>
> // NOTE: SRID will have to be changed after geometry creation
> static const GeometryFactory *geomFactory =
>        GeometryFactory::getDefaultInstance();
>
> This global geomFactory is called a number of times by WKB readers and
> some other functions.  I wonder if we can initialize it in initGEOS
> and clean it up in finishGEOS?
>
> It appears, that this is what used to happen? Here's the current code.
>
> void
> finishGEOS ()
> {
>        // Nothing to do
>        //delete geomFactory;
> }
>
> Any help on the history behind this global?
>
> P.
>