This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
-------- Original Message -------- Subject: Re: Debugging memory leaks Date: Fri, 15 Apr 2005 09:39:27 -0800 From: David Daney <ddaney@avtrex.com> To: Andrew Haley <aph@redhat.com>
Andrew Haley wrote: > I've been having a great deal of difficulty tracking down memory leaks > in libgcj. > > What I need is some sort of interface that allows me to enquire who > points to an object. The ideal interface would be something like > points_to (obj) -> obj. I realize that in practice there is a set of > objects that point to a particular object, but that doesn't concern > me: one is all I need. >
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.
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.
The memory log files. Typical example: 2 files, 001-nomem.log and 001-nomem.log.bytes
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.
Attachment:
memorydump.tgz
Description: GNU Zip compressed data
Attachment:
memorydumpanalize.tgz
Description: GNU Zip compressed data
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |