Re: [geos-devel] GEOS, Shapely, DLLs, and memory
On Wed, Apr 29, 2009 at 9:00 AM, geos-devel-requ...@lists.osgeo.org wrote: Date: Tue, 28 Apr 2009 20:34:58 +0100 From: Mateusz Loskot mate...@loskot.net Subject: Re: [geos-devel] GEOS, Shapely, DLLs, and memory To: GEOS Development List geos-devel@lists.osgeo.org Message-ID: 49f75a62.1030...@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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS, Shapely, DLLs, and memory
Ragi Y. Burhum wrote: On Wed, Apr 29, 2009 at 9:00 AM, geos-devel-requ...@lists.osgeo.org mailto:geos-devel-requ...@lists.osgeo.org wrote: Date: Tue, 28 Apr 2009 20:34:58 +0100 From: Mateusz Loskot mate...@loskot.net mailto:mate...@loskot.net Subject: Re: [geos-devel] GEOS, Shapely, DLLs, and memory To: GEOS Development List geos-devel@lists.osgeo.org mailto:geos-devel@lists.osgeo.org Message-ID: 49f75a62.1030...@loskot.net mailto:49f75a62.1030...@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 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] [GEOS] #250: geos_contains(multipolygon, polygon) returns false when it should return true
#250: geos_contains(multipolygon, polygon) returns false when it should return
true
+---
Reporter: cdestigter | Owner: geos-devel@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 3.1.1
Component: Default | Version: 3.0.0
Severity: Unassigned |Keywords:
+---
In geodjango:
{{{
#!python
from django.contrib.gis import geos
g1 = geos.GEOSGeometry('MULTIPOLYGON(((0 0,0 10,10 10,10 0,0 0)))')
g2 = geos.GEOSGeometry('POLYGON((1 1,1 2,2 2,2 1,1 1))')
g1.contains(g2)
= False
g2.within(g1)
= False
}}}
Both of the above should return True. The following combinations work fine
though:
polygon.contains(polygon)
multipolygon.contains(multipolygon)
polygon.contains(multipolygon)
It's possible this has been fixed in a more recent version, though I
couldn't find any existing tickets on it. Feel free to close if that's the
case, stating when it was fixed.
--
Ticket URL: http://trac.osgeo.org/geos/ticket/250
GEOS http://geos.refractions.net/
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite
(JTS).___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Re: [GEOS] #250: geos_contains(multipolygon, polygon) returns false when it should return true
#250: geos_contains(multipolygon, polygon) returns false when it should return true +--- Reporter: cdestigter |Owner: geos-devel@lists.osgeo.org Type: defect | Status: new Priority: major |Milestone: 3.1.1 Component: Default | Version: 3.0.0 Severity: Unassigned | Resolution: Keywords: | +--- Comment (by mloskot): I've added new unit tests for C API calls [source:trunk/tests/unit/capi/GEOSContainsTest.cpp GEOSContains] and [source:trunk/tests/unit/capi/GEOSWithinTest.cpp GEOSWithin] (see r2422). The tests include cases you've reported above as test case number 3 (see function ''void test3'', in both files). I've run the tests on Linux 64-bit, certainly, using GEOS from trunk and I couldn't reproduce your problem. IOW, all the tests cases pass as expected. -- Ticket URL: http://trac.osgeo.org/geos/ticket/250#comment:1 GEOS http://geos.refractions.net/ GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
