Opened 10 years ago
Closed 8 years ago
#2470 closed defect (duplicate)
WebTier-Crash: MgGeometry.intersection() not thread safe
Reported by: | andymorf | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Web API | Version: | 2.5.0 |
Severity: | critical | Keywords: | |
Cc: | External ID: |
Description
On a system under higher load, the use of MgGeometry.intersection() leads to frequent crashes of the Webtier (tomcat on the affected system). A debugging session showed that concurrent execution of geos::geom::Geometry::intersection() results in heap corruption and crashes the process (jvm, apache...)
Change History (7)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
If this is due to your own application code, I think you should probably consider reviewing your usage of MgGeometry and any other class in the MapGuide API. Any class in the MapGuide API will probably assume single-threaded usage, and you should use your language's threading libraries/syntax to protect access to such instances.
comment:3 by , 10 years ago
After interminable investigations it seems to me that this in a problem of the JVM using the MSVCR100.dll runtime and my new MapGuide and Geos-Dll are compiled with vc12-platform toolset (VS2013) - before switching the whole dev-env from vc10 to vc12 things worked ok. I even switched function MgGeosUtil::Intersection to the recommended and thread-safe version of the geos-c api (with *_r ending) and the crashes remained.
Debugging sessions allways resulted in access violations when freeing objects, mainly of type std::XYZ...
IMHO this rises a big question mark concerning reliability of the Mg-Java-API being compiled with VS2012/13 (as long as the JVM stays at 2010 runtime)!
comment:4 by , 10 years ago
Component: | General → Web API |
---|---|
Priority: | medium → high |
It sounds like STL objects (strings?) are travelling across the MapGuide <-> JVM boundaries. This should not be happening or allowed.
Can you start a new discussion thread on mapguide-internals? This sounds like a serious problem that needs some level of discussion.
comment:5 by , 10 years ago
I'm not sure how familiar you are with SWIG, but I notice that string parameters for any method in the Java wrapper are marshaled across as std::wstring objects instead of plain wchar_t C-strings.
This may be where our problems are.
comment:6 by , 10 years ago
I understand your suspicion - on the other hand I only see access violations/crashes within GEOS-classes and in my case the the arguments which are sent are of type MgGeometry which are not constructed within java (origin is always MgFeatureReader). All the other MgJavaAPI-calls in my servlets (a lot of them) seem to work ok.
After reading your RFC141 i must admit that I am using GEOS-3.3.x version but since already two years without any problem - problem arised when switching from vc10 to vc12.
comment:7 by , 8 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
I'm closing this as a duplicate of #2596 as i suspect the cause there is the same for the cause here: Geometry operations going through the WKTReader/WKTWriter in GEOS, which has the non-thread-safe CLocalizer.
Do you have sample code that uses MgGeometry.intersection() in a multi-threaded manner?
This will probably be a tough ask to ask for something to reproduce a multi-threading bug, but it's worth a try.