Modify

Opened 2 years ago

Last modified 3 days ago

#17184 reopened defect

Memory Leaks

Reported by: GerdP Owned by: GerdP
Priority: normal Milestone:
Component: Core Version:
Keywords: template_report Cc:

Description

What steps will reproduce the problem?

  1. Ctrl+N : Open new data layer
  2. Alt+Shift+V: Make sure Validator Panel is visible
  3. Draw a way without adding tags
  4. Upload (a popup shows that you have a way without tags)
  5. Press continue
  6. Press cancel in the following dialog
  7. Close all layers to get back to the "Getting Started" dialog
  8. Repeat steps 1-7
  9. Create heap dump with e.g. VisualVM and look at instances of ValidatorTreePanel

What is the expected result?

No or maybe 1 instance

What happens instead?

2 instances

Please provide any additional information below. Attach a screenshot if possible.

Working on a patch...

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-12-31 15:09:58 +0100 (Mon, 31 Dec 2018)
Build-Date:2018-12-31 14:24:10
Revision:14620
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14620 de) Windows 10 64-Bit
OS Build number: Windows 10 Home 1803 (17134)
Memory Usage: 707 MB / 1820 MB (560 MB allocated, but free)
Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080

Plugins:
+ OpeningHoursEditor (34535)
+ apache-commons (34506)
+ buildings_tools (34807)
+ download_along (34503)
+ ejml (34389)
+ geotools (34513)
+ jaxb (34506)
+ jts (34524)
+ o5m (34405)
+ opendata (34805)
+ pbf (34576)
+ poly (34546)
+ reltoolbox (34788)
+ reverter (34552)
+ utilsplugin2 (34793)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: Region [TMS_BLOCK_v2] Resetting cache
- W: Cannot start IPv4 remotecontrol https server on port 8112: Keystore was tampered with, or password was incorrect
- W: Cannot start IPv6 remotecontrol https server on port 8112: Keystore was tampered with, or password was incorrect

Attachments (1)

17184.patch (5.8 KB) - added by GerdP 2 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 Changed 2 years ago by GerdP

Owner: changed from team to GerdP
Status: assignednew

comment:2 Changed 2 years ago by GerdP

Resolution: fixed
Status: newclosed

In 14672/josm:

fix #17184: fix leaks in ValidateUploadHook and ValidatorTreePanel.destroy()

comment:3 Changed 2 years ago by simon04

Milestone: 19.01

comment:4 Changed 2 years ago by GerdP

Resolution: fixed
Status: closedreopened

I've now learned that I have to watch the mouse cursor position when doing my tests. I see very different results in the heap dumps depending on the panels that the mouse cursor was in. So, some of the leaks which I found in #17040 still exist, esp. those in the preferences dialog. Many elements of that dialog are only freed when a new Preference Dialog is created, so they are never reused but kept for as long as JOSM runs. Still trying to find the cause...

Changed 2 years ago by GerdP

Attachment: 17184.patch added

comment:5 Changed 2 years ago by GerdP

Attached patch is work in progress. Maybe not all changes are needed.

comment:6 Changed 2 years ago by GerdP

This patch seems to make it more likely that the add tag dialog "forgets" the keyboard. When I edit with this patch I often see
cases where the OK button is enabled but pressing enter has no effect.

comment:7 Changed 2 years ago by Don-vip

Milestone: 19.0119.02

comment:8 Changed 2 years ago by Don-vip

Milestone: 19.0219.03

comment:9 Changed 22 months ago by Don-vip

Milestone: 19.03

comment:10 in reply to:  6 Changed 9 months ago by skyper

Replying to GerdP:

This patch seems to make it more likely that the add tag dialog "forgets" the keyboard. When I edit with this patch I often see
cases where the OK button is enabled but pressing enter has no effect.

I notice the lost of focus almost all the time with dialogs like "download data" and "add tag". Have to recheck but think that #5280 and #13497 were not completely fixed.

comment:11 Changed 5 weeks ago by GerdP

In 17418/josm:

see #17184: Memory leaks

  • remove listener when layer is removed (regression of r13608)

comment:12 Changed 5 weeks ago by GerdP

In 17420/josm:

see #17184: Memory leaks

  • don't keep list of OSM data in validator tests (not a real problem, but makes it harder to find real leaks)

comment:13 Changed 5 weeks ago by GerdP

In 17421/josm:

see #17184: Memory leaks

  • reset field lastUsedNode in draw mode (not a real problem, but makes it harder to find real leaks)

comment:14 Changed 5 weeks ago by GerdP

In 17422/josm:

see #17184: Memory leaks

  • reset selection in selectRelationAction (not a real problem, but makes it harder to find real leaks)

comment:15 Changed 5 weeks ago by GerdP

In 35673/osm:

see #17184: Memory Leaks

  • clear references to command instances or OSM objects to ease finding of real memory leaks

comment:16 Changed 3 weeks ago by GerdP

In 17439/josm:

see #17184: Memory leaks

  • implement method clear() in GpxData and call it when the GpxLayer is destroyed

Reduces memory leak when GPX layers are merged. Without this change GC seems to be unable to free the memory for WayPoints

comment:17 Changed 3 weeks ago by GerdP

In 17440/josm:

see #17184: Memory leaks

  • remove more listeners in destroy()
  • reset fields which might reference OSM objects
  • call data.clearSelection when data layer is destroyed so that fewer actions keep references on OSM elements in that layer

My goal here: When a layer is closed JOSM should really allow to GC all OSM data and GPX data that was loaded before.

comment:18 Changed 2 weeks ago by GerdP

In 35682/osm:

see #17184: Memory Leaks

  • don't keep dialog in MultiTagAction, it is newly created each time when the shortcut is pressed
  • overwrite setVisible to clear tableModel in MultiTagDialog so that it doesn't keep refs to OSM objects
  • simplify code (sonar issues)

comment:19 Changed 2 weeks ago by GerdP

In 17455/josm:

see #17184: Memory leaks

  • don't keep ref to primitives, it isn't needed anywhere

comment:20 Changed 12 days ago by GerdP

In 17458/josm:

see #17184: Memory leaks

  • clear collection rememberMovements in OrthogonalizeAction when no edit layer exits
  • clear refs to layers which may disturb GC, maybe because of the complex cyclic deps

comment:21 Changed 10 days ago by GerdP

In 17461/josm:

see #17184: Memory leaks

  • clear refs to OSM objects when Extrude Mode is ended

comment:22 Changed 10 days ago by GerdP

In 17462/josm:

see #17184: Memory leaks

  • clear refs to OSM objects in popup memu of PropertiesDialog

comment:23 Changed 8 days ago by GerdP

In 17464/josm:

see #17184: Memory leaks

  • clear also refs to Conflicts which refer to OSM data in DataSet

comment:24 Changed 6 days ago by GerdP

In 17471/josm:

see #17184: Memory leaks

  • use String.intern() for field role in RelationMemberData constructor.
  • clear HistoryDataSet when last HistoryBrowserDialog instance is closed

We have route relations with +1000 members and +1000 versions. It's probably not a good idea to create all the RelationMemberData instances in advance. Will open a separate ticket for that.

comment:25 Changed 6 days ago by GerdP

In 17473/josm:

see #17184: Memory leaks

  • clear also virtual ways when exiting SelectMode

comment:26 Changed 3 days ago by GerdP

Seems I made some progress here. My last few edit sessions didn't show any leak regarding GPX data or OSM data (after upload and closing all layers). I only used buildings_tools and utilsplugin2 and of course lots of core actions/modes, so that doesn't mean much ;)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The owner will remain GerdP.
as The resolution will be set.
to The owner will be changed from GerdP to the specified user.
The owner will change to GerdP
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.