REAL SSCCE of my graphical interface with memory leaks

[Patricia Shanahan]

Ehm... now i think that you are right.


Yes I ran it for two hour and the memory grows up to 15.824 KB (Task
Manager Windows)


Yes I've to look in another place the problem of my memory error
(probably a memory leak , but i'm not a specialist i written this
program day by day not looking to the correct code but looking to make
it runs.

Now i have a program of 1300 lines of graphical interface and many
more to control it and i don't know where i have to look!
I need a tool that help me to find the problem, can you advice me a
freeware one?

....

Maybe it is time for some refactoring, with the objective of making the
program cleaner and easier to decompose, as well as ensuring all GUI
work is done in the event handling thread.

It is entirely possible that the refactoring will itself remove the
problem. If it does not, you will have a better base for SSCCE
construction. The SSCCE approach can be a good way of tracking down
problems, even if you never post them to a newsgroup. The idea is to
progressively simplify the program, removing everything that is not
essential to reproducing the bug.

In your case, the test should be whether you get an OutOfMemoryError if
you run the program with -Xmx set to a reasonable value. Any time you
remove something, and the bug goes away, you have a new clue about what
is going wrong.

Patricia

 

[Lew]

This is not evidence of a memory leak. You have shown us NO evidence that
there is a leak.

 

[Mark Space]

Yes I ran it for two hour and the memory grows up to 15.824 KB (Task
Manager Windows)

Just to re-iterate, you should reduce the heap size as much as possible,
and run until you get an out of memory exception. Then copy the stack
trace here so we can see it. Can't help you much until we see that error.

 

[Andrew Thompson]

[...]

I ran 'your'* code for 8 hours on Win XP Pro using

...
Yes I ran it for two hour and the memory grows up to 15.824 KB (Task
Manager Windows) ...

Forget about the Windows Task Manager, it's next to useless for these kind
of measurements ...

Lew mentioned that earlier. Daniel mentioned it again,
and I will add my agreement to both.

Don't use the Windows Task Manager as any sort of indication
of what is happening to your app. How Windows goes about
assigning memory to the JVM that runs your app., is a separate
matter.

If the size of the JVM in the task manager actually grows
too big to handle, that will cause a crash in Windows, but
there is nothing that a Java application can do about that -
it is a matter between Sun and Microsoft.

The tool I pointed you too earlier, jconsole, is one simple
way to get a view into the memory used by a Java app.
(somebody also pointed out the NetBeans Profiler, earlier,
but I suspect jconsole is every bit good enough for this job).
jconsole.exe should also be available on your local machine,
assuming it has a recent JDK installed (I see it came with
1.5 as well). jconsole can be found in the bin directory of
the JDK location.

Also, as suggested - severely limit the memory of the app.
in testing, so that if a memory leak really exists, it will
cause problems much sooner.

Until you can say you have seen *OutOfMemoryErrors,*
I am inclined to believe there is *no memory leak.*