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

[Ragi Y. Burhum]

On Wed, Apr 29, 2009 at 9:00 AM, <geos-devel-request at lists.osgeo.org> wrote:

> Date: Tue, 28 Apr 2009 20:34:58 +0100
> From: Mateusz Loskot <mateusz at loskot.net>
> Subject: Re: [geos-devel] GEOS, Shapely, DLLs, and memory
> To: GEOS Development List <geos-devel at lists.osgeo.org>
> Message-ID: <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.

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

Any other combination is undefined behavior by the C++ standard and although
it may be working on whatever vendor/version of the C++ compiler you are
using, it is not guranteed to work in the future.

GCC tends to be very forgiving about this and sometimes MSVC can also be (at
least when combining the same VC version of the C runtime with the C++
runtime in certain versions) which could explain why there haven't been any
crashes in the shapely test cases that are calling free on something new'ed.

Valgrind, Purify, etc would point out these issues right of the bat.

To fix it correctly you would need a function that encapsulates each of
those three freeing methods and document which one to use for each c-api or
something of that sort. In my case, I have been using the C++ ABI and just
rifting through the GEOS code to find out how it was allocated to match it
properly in combination with recompilation of the entire GEOS dll as I
explained earlier.

My two cents,

- Ragi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20090429/d65186e5/attachment.html