<br>On Wed, Apr 29, 2009 at 9:00 AM, <span dir="ltr"><<a href="mailto:geos-devel-request@lists.osgeo.org">geos-devel-request@lists.osgeo.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Date: Tue, 28 Apr 2009 20:34:58 +0100<br>
From: Mateusz Loskot <<a href="mailto:mateusz@loskot.net">mateusz@loskot.net</a>><br>
Subject: Re: [geos-devel] GEOS, Shapely, DLLs, and memory<br>
To: GEOS Development List <<a href="mailto:geos-devel@lists.osgeo.org">geos-devel@lists.osgeo.org</a>><br>
Message-ID: <<a href="mailto:49F75A62.1030503@loskot.net">49F75A62.1030503@loskot.net</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Charlie Savage wrote:<br>
><br>
><br>
>>> Well, there is another way (not necessarily "better"), which is to<br>
>>> compile the GEOS dll yourself using the same runtime that you use in<br>
>>> your main application. That is what I have been doing this whole time to<br>
>>> avoid this issue.<br>
>><br>
>> It will not help.<br>
><br>
> Actually Ragi is correct, that does work.<br>
<br>
Charlie, Ragi,<br>
<br>
I take it beck. Yes, you are right.<br>
Replying in rush, I've missed the fact Ragi is talking<br>
about "the same runtime" what I read as "the same compiler"<br>
and corrected as same compiler != same runtime.<br>
<br>
>> You must not cross modules boundaries, it's well known issue on Windows<br>
>> platform.<br>
><br>
> If an executable and its dlls link against the exact same runtime<br>
> library, you can cross module boundaries because all the memory and file<br>
> handles are managed by the same instance of the runtime library (so in<br>
> effect you aren't crossing runtime library boundaries).<br>
<br>
Yes, same runtime, yes.<br>
<br>
Best regards,<br>
--<br>
Mateusz Loskot, <a href="http://mateusz.loskot.net" target="_blank">http://mateusz.loskot.net</a><br>
Charter Member of OSGeo, <a href="http://osgeo.org" target="_blank">http://osgeo.org</a><br>
<br></blockquote></div><br>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).<br>
<br>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.<br>
<br>We all know the rule. Match:<br>malloc with free<br>new with delete<br>new [ ] with delete [ ]<br><br>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.<br>
<br>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.<br>
<br>Valgrind, Purify, etc would point out these issues right of the bat.<br><br>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.<br>
<br>My two cents,<br><br>- Ragi<br>