Ticket #669 (closed defect: fixed)
Opened 2011-07-08T17:04:18-05:00
Last modified 2011-07-14T14:27:57-05:00
IJ2 seems to be holding onto memory
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Legacy Compatibility | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
After running a while (lots of Stack to Images runs) IJ2 craps out with an out of memory issue.
Change History
comment:1 Changed 2011-07-12T15:00:17-05:00 by bdezonia
comment:2 Changed 2011-07-12T15:02:03-05:00 by bdezonia
The memory issues do not cause an exception. But hatching new windows by the plugin slows more and more until its glacial. Closing these windows then will complain about memory issues.
comment:3 Changed 2011-07-12T15:13:24-05:00 by bdezonia
Sequence to repeat was poorly formatted.
To repeat error do:
Open Organ Of Corti
Image Stacks :: Delete Data (12 Z's)
Image Stacks :: Stack To Images
Close all open windows
comment:4 Changed 2011-07-12T15:31:43-05:00 by bdezonia
A simpler experiment
- repeatedly run and close Help About ImageJ (IJ1)
- notice that allocated memory climbs and climbs
comment:5 Changed 2011-07-13T13:16:21-05:00 by bdezonia
Found that the majority of leaked memory is JMenuItems (on the Mac each window has its own menu of JMenuItems) and int[] (position and extent variables I think).
To handle int[] work on ticket about minimizing creation of int[] via precreation and passing into routines. Not sure why they are never getting reclaimed. Imglib issue maybe?
To handle JMenuItem issue tried making a call to dispose() when Window closes. Doesn't seem to fix thing. May need to set menu to null first which would be a bug workaround.
comment:6 Changed 2011-07-13T17:21:21-05:00 by bdezonia
Found the memory leak and have put in a temporary fix in SwingImageDIsplay::close(). See 7c98f9e1b79cec6e009073d01f5ead6bc1ae33af.
The test for this bug is:
File New Hyperstack 8-bit 300x200x10
Stack To Images
Close all images
Using JConsole run GC and notice memory returns to where it was.
Used Eclipse Memory Analyzer to hunt for leaks.
comment:7 Changed 2011-07-14T11:08:16-05:00 by bdezonia
Improved fix (see b77af4ce959a85df7d523291d8a0f39eb0caae5c).
There are still the original byte[] data and the associated int[] display data left around. Will tackle that next.
comment:8 Changed 2011-07-14T11:58:38-05:00 by bdezonia
Also it seems there are hundreds of int[256]'s left around. ColorTable8's I'd say.
comment:9 Changed 2011-07-14T12:13:38-05:00 by bdezonia
if open new HyperStack of 10 8-bit 300x200 slices the memory analyzer shows about 400 int[256]'s unreclaimed by garbage collector.
comment:10 Changed 2011-07-14T14:27:57-05:00 by bdezonia
- Status changed from new to closed
- Resolution set to fixed
Fixed all known memory leaks in 93b146572a7afa2a109415c1669f60ada5743a40, 2086628b52b400c3754002b6ac32e64ac7bc9244, 52a06860d77807af74a26cb9c9876841e511c501, and 013bc9f9001d5c3e20e6422fe0cc044b1271a29c.
There is some question as to why so many ColorTable8's are getting created. Maybe we should investigate.
Found one memory leak in SwingDisplayWindow. Fixed in b273a2e45967134019d41378eb083cd649cfcdb7.
However you can get memory issues if you do this repeatedly: