[geos-devel] GEOS, Shapely, DLLs, and memory

[Mateusz Loskot]

Ragi Y. Burhum wrote:
> 
> On Wed, Apr 29, 2009 at 9:00 AM, <geos-devel-request at lists.osgeo.org 
> <mailto:geos-devel-request at lists.osgeo.org>> wrote:
> 
>     Date: Tue, 28 Apr 2009 20:34:58 +0100
>     From: Mateusz Loskot <mateusz at loskot.net <mailto:mateusz at loskot.net>>
>     Subject: Re: [geos-devel] GEOS, Shapely, DLLs, and memory
>     To: GEOS Development List <geos-devel at lists.osgeo.org
>     <mailto:geos-devel at lists.osgeo.org>>
>     Message-ID: <49F75A62.1030503 at loskot.net
>     <mailto:49F75A62.1030503 at loskot.net>>
>     Content-Type: text/plain; charset=UTF-8
> 
>     Charlie Savage wrote:
>      >
>      >
>      >>> Well, there is another way (not necessarily "better"), which is to
>      >>> compile the GEOS dll yourself using the same runtime that you
>     use in
>      >>> your main application. That is what I have been doing this
>     whole time to
>      >>> avoid this issue.
>      >>
>      >> It will not help.
>      >
>      > Actually Ragi is correct, that does work.
> 
>     Charlie, Ragi,
> 
>     I take it beck. Yes, you are right.
>     Replying in rush, I've missed the fact Ragi is talking
>     about "the same runtime" what I read as "the same compiler"
>     and corrected as same compiler != same runtime.
> 
>      >> You must not cross modules boundaries, it's well known issue on
>     Windows
>      >> platform.
>      >
>      > If an executable and its dlls link against the exact same runtime
>      > library, you can cross module boundaries because all the memory
>     and file
>      > handles are managed by the same instance of the runtime library
>     (so in
>      > effect you aren't crossing runtime library boundaries).
> 
>     Yes, same runtime, yes.
> 
>     Best regards,
>     --
>     Mateusz Loskot, http://mateusz.loskot.net
>     Charter Member of OSGeo, http://osgeo.org
> 
> 
> I took a quick a look at the patch and it seems that it may be incorrect 
> (I may be wrong if I am missing something obvious like some operator new 
> /delete overloading or some obscure memory management in GEOS that I 
> completely missed).
> 
> The patch calls for a GeosFree function that calls free(), however, most 
> of the functions are allocated with new (in fact, I only found 6 places 
> in trunk where malloc is used whereas new is all over the place). This 
> patch in fact, would potentialy make you mix runtimes.


Ragi,

AFAIU, this patch is supposed to be used against string of
characters and byte arrays, like WKT string etc.
These are allocated using std::malloc.

Users are supposed to deallocate objects with corresponding deallocators 
like functions

GEOSGeom_destroy for GEOSGeometry
EOSCoordSeq_destroy for GEOSCoordSequence
etc.

There is lack of deallocator for GEOSGeomToWKT and GEOSGeomToWKB
and this patch, AFAIU, is supposed to cover it.

Perhaps it would be better to rename GEOSFree to GEOSBufWKT_destroy
and GEOSBufWKB_destroy, for clarity.

> We all know the rule. Match:
> malloc with free
> new with delete
> new [ ] with delete [ ]

Yes, you're perfectly right.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net