View Issue Details

IDProjectCategoryView StatusLast Update
0017772MMW 5Main Panelpublic2021-05-20 18:11
ReporterLudek Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0.1Fixed in Version5.0 
Summary0017772: Significant memory leak while browsing content
DescriptionDuring today's inspecting of memory allocations of MM5 found significant memory leak while browsing content.

Steps to replicate:
1) expand Music node
2) click Music > All tracks and wait for tracks to be loaded
3) click Playing node
repeat the steps 2&3 repeatedly
=> memory is still growing
TagsNo tags attached.
Fixed in build2338

Relationships

related to 0017547 closedmichal Playing mm for hours (--> crash 875B000 : fixed) --> increased memory utilization 

Activities

Ludek

2021-04-19 22:30

developer   ~0062883

Last edited: 2021-04-19 22:50

Fixed in 5.0.1.2400 and merged to 5.0.0.2338 (as it is low risk fix of a significant mem leak)

rusty

2021-04-20 18:20

administrator   ~0062892

Last edited: 2021-04-20 18:25

Tested build 2338 and I'm not sure if it's completely fixed: initial memory utilization of 235MB grows to 320MB after switching through the following cycle 50 times:
Playing [List] --> Music [Browser] --> Music>All Tracks [List] --->...

EDIT: removing the middle step of switching to the Music [Browser] node eliminates the increase in memory utilization, so this is probably related to caching of artwork?

Ludek

2021-04-20 20:33

developer   ~0062893

ok, moving target 5.0.1 to continue inspecting possible leaks further...

Test note: There is a cache that the last three views are cached (including its data sources) for 1 minute and the last view is always cached. So in the tests the mem usually decreases after 1 minute (once the cache for the three views is cleared)

Ludek

2021-04-20 20:51

developer   ~0062894

Last edited: 2021-04-20 20:52

Otherwise in your test case including Music [Browser] started at 225 MB and was able to go over 270 MB once upon a time, but one minute later it decreased to 227 MB.
Though the new debug strings re allocated objects (that I added for 5.0.1.2400) shown that album object is leaking, so there are still probably some leaks, but the one fixed for 5.0.0 was huge.
Let's continue with inspecting the smaller leaks for 5.0.1...

peke

2021-04-21 10:53

developer   ~0062900

Confirming Leak fix in 2238

To test I used Scanning into library around 80k of tracks AA Lookupenable and view was in Browser+grid Sorted descending so that Z is last one and view constantly refreshes. Start was 230MB left it for 6h to scan and cache artworks.

This morning mem utilization was around 280MB but it is normal due the AA caching.