[MAPSERVER-USERS] missing lock in mapfile.c:msFreeLabelCacheSlot() ?

[rich.fromm]

I have a custom Java webapp that uses Java mapscript and is running with
tomcat.  Each flow from request to response is a single thread, but tomcat
is
able to process multiple concurrent requests if it receives them.

I was previously having a problem that I at first thought was a
multithreading
issue, but turned out to be a memory leak:
  http://trac.osgeo.org/mapserver/ticket/2525
  http://www.nabble.com/thread-safety-to15514019.html

I have patched my code and the memory leak is now solved.  I can run fairly
long stress tests (so far as long as 14 hours) with a client sequentially
requesting maps and everything runs fine.  But if I have my client make
concurrent requests, the mapscript code inevitably throws a SIGSEGV,
crashing
the JVM and tomcat.  This usually happens sometime within the first or
second
hour of my stress test.  All times (5 so far), the stack trace has been
entirely identical, starting with a Java mapscript call to mapObj.delete().

--- begin ---
(msFreeLabelCacheSlot) mapfile.c:4068
(msFreeLabelCache) mapfile.c:4100
(msFreeMap) mapobject.c:98 (*)
(delete_mapObj) mapscript/java/mapscript_wrap.c:1619 (**)
(Java_edu_umn_gis_mapscript_mapscriptJNI_delete_1mapObj)
mapscript/java/mapscript_wrap.c:19695 (***)

code is compiled with -O2 (aside, is this possible to change when running
configure?), so i'm not too surprised at possible slight differences in line
numbers:

(*)   should probably be mapobject.c:96.
(**)  should probably be mapscript_wrap.c:1618
(***) should probably be mapscript/java/mapscript_wrap.c:19693
--- end ---

I'm wondering if there is perhaps some lock that is needed with respect to
the
label cache that might be missing.

Is there some way that I can disable the label cache (presumably at a cost
of
performance) to see if the crash still occurs?

I see that a comment in mapthread.c notes:

--- begin ---
1) It is currently assumed that a mapObj belongs only to one thread at a
time.
That is, there is no effort to syncronize access to a mapObj itself. 
--- end ---

I am adhering to this.  Each request is processed in a single thread, and
that
thread creates its own mapObj and calls delete() on it when done, and no
other
thread ever has access to the mapObj.

I don't yet have a fully self contained test case for this using Java
mapscript independent of tomcat, but I could work on creating one.

I am running mapserver 5.0.0, locally patched to fix bug 2525 as noted
above.
This is on debian 3.1 (sarge), locally compiled with gcc 3.3.5, using
locally
compiled versions of GD 2.0.35 and AGG 2.5, and debian packages for
everything
else.  My mapserver configuration is as follows:

MapServer version 5.0.0 OUTPUT=GIF OUTPUT=PNG OUTPUT=WBMP OUTPUT=SVG
SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=THREADS INPUT=POSTGIS
INPUT=SHAPEFILE

The Java mapscript code was compiled with SWIG 1.3.24 and Sun Java 1.5.0_06.
It runs with the same version of Java and with tomcat 5.5.17.  It queries
its
data from a PostgreSQL/PostGIS database, uses projections, uses the AGG
renderer, includes labels with TrueType fonts, and generates PNG output.  I
think that what I'm doing ought to be thread safe, although I can't say that
100% certain of that.

Thanks for any help that anyone might be able to provide.

- Rich

-- 
View this message in context: http://www.nabble.com/missing-lock-in-mapfile.c%3AmsFreeLabelCacheSlot%28%29---tp15699786p15699786.html
Sent from the Mapserver - User mailing list archive at Nabble.com.