Hi Rich I saw, that you made a thread on java/threading/memory-leaks "on your own". Although I spend some time on the same issues in the last years I can hardly give new input.
Don't know wether you saw these: 1. http://www.nabble.com/forum/ViewPost.jtp?post=5707320&framed=y We worked around threading-problems with Java-synchronizing. By doing so, the application becomes stable in stress-tests, but looses the ability to use many CPUs. (On the other hand: http://www.nabble.com/forum/ViewPost.jtp?post=15410399&framed=y shows, that the mapserver-locks prevent using many CPU's in any case.) 2. You cited the post about the delete-problem. (http://www.nabble.com/forum/ViewPost.jtp?post=1548675&framed=y) This issue was adressed in Mapserver 5.0: http://mapserver.gis.umn.edu/development/rfc/ms-rfc-24 So the garbage-collector shouldn't crash the jvm any more. (My personal opinion is to use delete anyway, since freeing C-memory in the garbage-collector-thread sounds dangerous to me. But as far as I know, there are no more documented problems.) 3. I also spent time in watching memory-leaks inside Mapscript/java and abandoned valgrind-approach. Seemed to be to complex, since much memory-handling of the JVM is documented. My approaches: Variant 1: In cases, where I had a guess what to look for, I wrote a small C-program, which called the suspect functions and analysed the behaviour of this small program. (Successfully used in http://trac.osgeo.org/mapserver/ticket/1662.) Didn't use valgrind but memwatch ( http://www.linkdata.se/sourcecode.html). But this is purely a matter of taste. Disadvantage: Doesn't help, if you have no guess. Variant 2: Watching memory-usage using top from outside during stress-tests. With some awk-sed-batch-unix-stuff it resulted in pictures like this: http://trac.osgeo.org/mapserver/attachment/ticket/1662/before-after.zip Disadvantage: Black box Sorry. That's hardly helpfull. But I'm interested in your progress. Benedikt Rothe [EMAIL PROTECTED] schrieb am 20.02.2008 02:26:04: > > Any advice about tracking down memory leaks that might exist in java > mapscript? > > For the context of why I'm trying to do this, see the following thread: > > http://www.nabble.com/thread-safety-to15514019.html > > I installed the debian sarge backport of valgrind (valgrind-3.2.0-Debian), > and > tried invoking java prefaced with: > > valgrind --leak-check=full --smc-check=all -v > > No leaks were reported, but I don't think it really checked where I wanted > it > to check. libmapscript.so is loaded with the following: > > System.loadLibrary("mapscript"); > > And from the output it doesn't look like valgrind is actually instrumenting > that library, and I can't figure out how to tell it to explicitly instrument > a > dynamically loaded library. > > Yet the valgrind FAQ: > > http://valgrind.org/docs/manual/faq.html#faq.java > > does indicate that this might at least be possible: > > --- begin --- > in theory Valgrind can run any Java program just fine, even those that use > JNI and are partially implemented in other languages like C and C++. In > practice, Java implementations tend to do nasty things that most programs > do not, and Valgrind sometimes falls over these corner cases. > --- end --- > > Sorry if this is more appropriately a valgrind question and not a mapserver > question, but I saw valgrind mentioned in a few places: > > HISTORY.TXT > http://trac.osgeo.org/mapserver/ticket/2412 > > so I thought that maybe someone here might have experience as it relates to > this specific case. > > - Rich > > -- > View this message in context: http://www.nabble.com/detecting- > memory-leaks-in-java-mapscript-tp15580371p15580371.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
_______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
