[MAPSERVER-USERS] msProcessProjection(): Projection library error.

[rich.fromm]

I'm not sure if anyone is going to be able to be of any help with this, since
I am not able to consistently reproduce the problem.  Nevertheless, based on
previous instructions, just in case, I am reporting a rare problem seen
under
heavy load.

I am stress testing a custom webapp using java mapscript.  On several
occasions, I have observed mapserver logging an error, which caused tomcat
to
return a 500 (Internal Server Error), but NOT crash.  The error is as
follows:

--- begin ---
java.lang.UnknownError: msProcessProjection(): Projection library error. no
system list, errno: 22

        at edu.umn.gis.mapscript.mapscriptJNI.new_mapObj(Native Method)
        at edu.umn.gis.mapscript.mapObj.<init>(mapObj.java:288)
--- end ---

I assume this is being logged at mapfile.c:967

If I later by hand try the exact same query that causes this to happen, the
query works fine.

Because of this, I then added a (limited) auto-retry mechanism to my java
code.  After running fine for a significant amount of time (hours) under
heavy
load, I got a very similar, though not entirely identical java stack trace:

--- begin ---
java.lang.UnknownError: msProcessProjection(): Projection library error.
        at edu.umn.gis.mapscript.mapscriptJNI.new_mapObj(Native Method)
        at edu.umn.gis.mapscript.mapObj.<init>(mapObj.java:288)
--- end ---

Right around here, tomcat DID crash, with a SIGSEGV.  I know that my code
properly caught the error and was preparing to retry.  I suspect it may have
been the retry that caused the crash, but I unfortunately don't have enough
logging information to prove that. I am in the process of running again,
with
some more logging, to try to get a better feel for what happens in the event
of this mapserver error and retry.

Anyway, here is the stack trace:

_IO_fread (/lib/libc.so.6)
yy_get_next_buffer (maplexer.c:3522)
msyylex (maplexer.c:3353)
loadLayer (mapfile.c:2572)
loadMapInternal (mapfile.c:4353)
msLoadMap (mapfile.c:4578)
new_mapObj (mapscript/java/mapscript_wrap.c:1612)
Java_edu_umn_gis_mapscript_mapscriptJNI_new_1mapObj
(mapscript/java/mapscript_wrap.c:19633)

Regardless of the fact that that is where the actual segfault occurred, I
refuse to believe that this is a sign of a bug in glibc.

Confounding things further, the very first time I tried running again to
debug
this situation, the very first request (but with different parameters than
above) also crashed tomcat, with the same crash as above.  And this time
there
was NOT any evidence of a projection error or a retry.

But that was the only such instance, and since then I have yet to see either
the projection error or tomcat crashing.  I am continuing a stress test with
more logging and will report if I have anything new to add.

I have locally compiled mapserver 5.0.0 plus patches for bug 2525 and bug
2497.  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 (8.1) / PostGIS (1.1.2) database, uses projections,
uses the AGG renderer, includes labels with TrueType fonts, and generates
PNG
output.

The data for each LAYER has the following input projection:

        PROJECTION
	        "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"
        END        

And the MAP defines the following output projection:

    PROJECTION
	    "+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84
+units=m +no_defs"
    END

Thanks if anyone has anything helpful to add, but I'm not expecting it and
am
mostly posting this just to record the problem.  Given the relative
infrequency of the problem, and the fact that (I think) further retrying the
same request will eventually work, I may be satisfied with just having a
watchdog process that automatically restarts tomcat in the event that it
does
crash.

Based on the sporadic nature of what I'm seeing, it's entirely possible that
there's just some more fundamental multithreaded issue going on, and the
spot
reporting a problem is not at all what's responsible.

For a related issue of a moving around crash under heavy load, see the
following mailing list thread:

http://www.nabble.com/missing-lock-in-mapfile.c%3AmsFreeLabelCacheSlot%28%29---to15699786.html

-- 
View this message in context: http://www.nabble.com/msProcessProjection%28%29%3A-Projection-library-error.-tp15815968p15815968.html
Sent from the Mapserver - User mailing list archive at Nabble.com.