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 jng, 10 years ago

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.

comment:2 by jng, 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 andymorf, 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 jng, 10 years ago

Component: GeneralWeb API
Priority: mediumhigh

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 jng, 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.

See: http://trac.osgeo.org/mapguide/browser/branches/2.6/MgDev/Web/src/MapGuideApi/MapGuideApiGen.xml#L36

This may be where our problems are.

comment:6 by andymorf, 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 jng, 8 years ago

Resolution: duplicate
Status: newclosed

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.

Note: See TracTickets for help on using tickets.