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. _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
