[MAPSERVER-USERS] leaking memory in java mapscript (was Re: thread safety)

[rich.fromm]

Benedikt Rothe wrote:
> 
> Sorry. That's hardly helpfull. But I'm interested in your progress.
> 

Thanks for your input.  It's not "hardly helpful".  But I will give a few
clarifications:

1) I think my threading worries may have been a red herring.  When I started
   experiencing JVM crashes during stress tests that were not reproducible,
my
   first conclusion was a threading problem.  But further investigation
points
   to memory leaks, esp. since I can crash the JVM even with a sequential
test
   client.  I can watch the memory consumption with top, and eventually it
   runs out of memory and crashes the JVM and tomcat dies.  I can somewhat
   ironically cause the crash to happen faster by allocating more memory to
   tomcat, since that leaves less memory available for the JNI code.

2) I don't think it's the gc that's crashing the JVM.  It's just that the
JNI
   code is out of memory, so some malloc is going to fail.  But it doesn't
   cleanly report that back to Java as an OutOfMemoryError, the malloc just
   returns a null.  So something that ought to be pointing to valid memory
in
   the JNI code is now pointing to null, and when that pointer is
   dereferenced, it causes a segfault, which crashes the JVM.

3) As far as I can tell, I am calling delete() for every mapserver object
that
   I reference as soon as I am done with it.  Yet the code is still leaking
   memory, leading me to suspect an actual memory leak internal to mapserver
   (or the mapscript interface).

4) Valgrind seems very useful for tracking down the problem in (3), if I can
   get it to work.  In theory (based on the reading the FAQ and the valgrind
   mailing list), I think I ought to be able to do this.  But I think my
   problem is that it's not even instrumenting libmapscript.so, and I can't
   figure out why.  For more details:

  
http://www.nabble.com/memcheck-of-JNI-library-loaded-via-System.loadLibrary%28%29-to15582655.html

So my approach right now is to try and get valgrind to work.  If that
doesn't
work, another tool that was suggested to me (besides memwatch) is memprof:

   http://www.gnome.org/projects/memprof/

And taking java out of the loop might simplify things, but I'm not sure how
easy or hard that might be.  There is no C or C++ mapscript, but I suppose
if
I take a look at what mapscript is really doing under the covers, I could
write a pure C or C++ program that links in libmapscript.so.

Only after I solve the memory problem will I take a look at multithreaded
issues.

- Rich

-- 
View this message in context: http://www.nabble.com/thread-safety-tp15514019p15596694.html
Sent from the Mapserver - User mailing list archive at Nabble.com.