Ticket #669 (closed defect: fixed)

Opened 8 years ago

Last modified 8 years ago

IJ2 seems to be holding onto memory

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: biweekly-2011: Jul-05 to Jul-15
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 8 years ago by bdezonia

Found one memory leak in SwingDisplayWindow. Fixed in b273a2e45967134019d41378eb083cd649cfcdb7.

However you can get memory issues if you do this repeatedly:

Open Organ Of Corti

Image
Stacks :: Delete Data (12 Z's)
Image
Stacks :: Stack To Images Close all open windows

comment:2 Changed 8 years ago 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 8 years ago 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 8 years ago by bdezonia

A simpler experiment

  • repeatedly run and close Help About ImageJ (IJ1)
  • notice that allocated memory climbs and climbs

comment:5 Changed 8 years ago 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 8 years ago 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 8 years ago 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 8 years ago by bdezonia

Also it seems there are hundreds of int[256]'s left around. ColorTable8's I'd say.

comment:9 Changed 8 years ago 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 8 years ago 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.

Note: See TracTickets for help on using tickets.