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