Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 496227

Summary:

Memory leak relating to selection handles

Product:

[Tools] GEF

Reporter:

Colin Sharples <ctg>

Component:

GEF FX

Assignee:

Alexander Nyßen <nyssen>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

nyssen

Version:

0.2.0

Target Milestone:

4.1.0 (Neon.1) M1

Hardware:

OS:

Windows 10

Whiteboard:

Bug Depends on:

Bug Blocks:

498045

Attachments:

Description	Flags
Heap dump with no parts selected	none
Heap dump after first part is selected	none
Heap dump after second selection	none

Description Colin Sharples

2016-06-15 18:50:27 EDT

There appears to be a memory leak where selection handle parts are retained in memory somewhere. 

Steps to recreate:

1. In the GEF4 Logo Example application, modify FXLogoSelectionHandlePartFactory to override createHandleParts(), and call System.gc() before calling super.createHandleParts() (just to give the JVM every chance to reap stale objects before creating new handles).

2. Run the GEF4 Logo Example application

3. Run JConsole and connect to the example application

4. Take a heap dump of the application before interacting with any of the parts

5. Select the horizontal connector at the top of the logo. Take another heap dump of the application.

6. Select the horizontal connector at the bottom of the logo. Take a third heap dump of the application.

7. Open the three heap dumps in Eclipse Memory Analyzer, and open the histogram in each dump. Enter "HandlePart" as the filter, and sort by Objects. Observe the counts for FXCircleSegmentHandlePart:

Dump 1 (pre-selection): 0
Dump 2 (after first selection): 5
Dump 3 (after second selection): 10

Expected that Dump 3 would also show 5, after the handle parts from the first selection had been garbage collected. Something must be retaining a reference to the handle parts even after they have been removed from the scene.

Comment 1 Colin Sharples

2016-06-15 18:53:15 EDT

Created attachment 262479 [details]
Heap dump with no parts selected

Example heap dump immediately after opening the application, with no parts selected.

Comment 2 Colin Sharples

2016-06-15 19:02:08 EDT

Created attachment 262480 [details]
Heap dump after first part is selected

After selecting the first connector

Comment 3 Colin Sharples

2016-06-15 19:05:31 EDT

Created attachment 262481 [details]
Heap dump after second selection

After selecting the second connector

Comment 4 Alexander Nyßen

2016-07-15 07:39:30 EDT

This results from missing dipose() calls on the handle and feedback parts that are being removed. I pushed the following changes to origin/master and origin/R4_0_maintenance:

- Ensured that AbstractBehavior disposes all handle and feedback parts it removes.
- Ensured that ContentBehavior disposes the contents parts within its pool when being disposed.

Resolving as fixed in 4.1.0 M1.