[Fwd: Re: Debugging memory leaks]

Tue Nov 22 03:43:00 GMT 2005

David Daney wrote:
> This is a message I originally sent privately to Andrew Haley, however 
> it might be useful with your problem as well (and the gcj community in 
> general).
>> David Daney
>> We have exactly this. I don't think it works with the BC_ABI. Also it
> is only tested on mipsel-linux. gcj-3.4.3
>> The things in memorydump.tgz are linked into the application under test.
> We added it to libgcj.
>> memorydumpanalize.tgz analizes the dump off-line.
>> To generate the dump do:
>> com.avtrex.test.memory.GCInfo.enumerate("%03d-dump.txt");
>> To analize the dump do:
>> java -Xmx512m com.avtrex.test.analyze.MemoryAnalyze [name_of_dump_file]
>> The executable image and libgcj.so must be in the current directory.
> Also the name of nm (mipsel-linux-nm) is hard coded so you will have to
> fix that.
>> The code is a bit of a hack. If you like it I was thinking of cleaning
> it up and contributing it to GCC.
>> More instructions:
>> Put all of these items in a directory:
>> The memory log files. Typical example: 2 files, 001-nomem.log and
> 001-nomem.log.bytes
>> The excutable program
>> The gcj library (like libgcj.so.4.0.0 or libgcj.so.4.0.0.nomal)
>>> Cd to that directory
>>> Java â€“Xmx512m â€“cp analyze.jar com.avtrex.test.analyze.MemoryAnalyze
> 001-nomem.log
>>> Be sure to use a full path for analyze.jar if it isnâ€™t in the current
> directory, and replace 001-nomem.log with the appropriate memory dump 
> file.
>David:
Thank you so very much for this instrumentation code. It has already 
been TREMENDOUSLY helpful. We had some problems getting it working, 
principally with a Integer vs. Long issue where (apparently) older Java 
versions could parse 32-bit addresses in hexadecimal string format with 
Integer.parseInt(). I found out that this is no longer true, and I had 
to make some modifications to your analysis code to get it to work. I'm 
happy to send you those changes if you so desire.
We are having one problem with your tool though, and that's with symbol 
names. SymbolTable.java is able to find symbols from the GCJ library 
perfectly well, but it cannot seem to find symbols from our application, 
even though the obvious things are in place:
1. Our GCJ executable has not been stripped, and "nm" shows the 
symbols/addresses
2. SymbolTable.java reads 42,000+ symbols when it runs nm
So, apparently something is amiss, but it doesn't seem to be too obvious 
at the moment. If you have any ideas, they would be greatly appreciated.
Mostly, thanks so much for bailing us out. We were lost without your 
tool. Now, things are beginning to come into focus, and it's clear that 
our application is holding references to some things that it shouldn't 
be. Thanks to your tool, we already know what those things are. Now we 
just have to figure out why. Getting app classnames into the dump from 
your tool would help.
Andrew and others - please, for the love of god... consider integrating 
David Daney's GC dump tool into GCJ. It's small, powerful, 
non-invasive, and damn useful. This is something that GCJ deserves to 
have!!
Best Regards,
craig vanderborgh
voxware incorporated