View Issue Details

IDProjectCategoryView StatusLast Update
0021182MMW 5Tagging / organizing (properties / auto-tools)public2024-09-15 19:14
Reporterlowlander Assigned To 
PriorityimmediateSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version5.1 
Target Version5.1Fixed in Version5.1 
Summary0021182: Editing Properties Memory Leak
DescriptionIt seems that during editing Properties of Albums there is a memory leak. What exactly triggers this I'm unsure. It seems per edited Album memory use increases ~10MB.

Things done during Properties edit:
1. Manually fill in Genre, Date, Original Date and Custom 1.
2. Sometimes fix Artist, Album, Album Artist
3. Paste Comment from Firefox
4. Paste Mood and Occasion from Notepad
5. Add Artwork via URL, sometimes via Artwork lookup

Then there may be in-line edits:
1. Title fixes
2. Adding Original Date

Lastly files:
1. Get Volume Analyzed
2. Added to Playing

It seems Properties edits is the issue.
TagsNo tags attached.
Fixed in build3054

Relationships

related to 0020906 assignedpetr AV EFBE0000 (out of memory) / navigating menus increases memory utilization 
related to 0021188 assignedLudek Lyrics Auto Lookup in Preview Memory Leak 
related to 0021200 closedLudek Expanding Artists node on large DB => out of memory (regression 3050) 

Activities

Ludek

2024-09-05 12:23

developer   ~0076842

Last edited: 2024-09-05 12:26

I can't replicate the cover/artwork items leaking, but could you please do following test:

1) Open Properties > Artwork on an album, right-click > Open DevTools in Chrome
2) Go to Memory page and take 'Snapshot 1'
3) Close Properties and re-open Properties > Artwork on another album and take 'Snapshot 2'
4) Close Properties and re-open Properties > Artwork on another album and take 'Snapshot 3'
5) Check objects allocated between 'Snapshot 2' and 'Snapshot 3'
=> there are some
6) Close Properties, re-open and check objects allocated between 'Snapshot 2' and 'Snapshot 3' again
=> there should by any (as on the following screenshot)
image.png (33,515 bytes)   
image.png (33,515 bytes)   

Ludek

2024-09-05 12:31

developer   ~0076843

Last edited: 2024-09-05 12:34

OK, actually there can be some objects allocated between the snapshots, but the overal memory should still stay the same (28 MB in my case), see the screenshot:
I guess that in your case it grows? If yes, then please save the memory profile (Ctrl + S) and share the '.heapsnapshot' file
image-2.png (57,662 bytes)   
image-2.png (57,662 bytes)   

lowlander

2024-09-06 17:45

developer   ~0076881

I think I did as requested, however this is not what causes the problem. I do various editing when memory usages increases.
image-3.png (91,424 bytes)   
image-3.png (91,424 bytes)   
image-4.png (155,556 bytes)   
image-4.png (155,556 bytes)   
image-5.png (154,441 bytes)   
image-5.png (154,441 bytes)   
image-6.png (154,933 bytes)   
image-6.png (154,933 bytes)   
image-7.png (157,709 bytes)   
image-7.png (157,709 bytes)   
image-8.png (158,585 bytes)   
image-8.png (158,585 bytes)   

Ludek

2024-09-11 13:14

developer   ~0076904

Thanks for the screencast video!

Thanks to the screencast I was able to replicate and sawing instantly growing TCover items in the debug log like:
[12160] MM5 [9328](R) Allocated TCover: 50, delta: 25
after using the 'Add cover' dialog to add the cover..

..but found out that this items are garbage collected, but after minute or two, so if I left MM5 untached then I saw 2 minutes later in the log lines like this:
[12160] MM5 [6228](R) Allocated TCover: 25, delta: -60
i.e. the TCover items were garbage collected..

I am not too familiar with Chromium's garbage collector, but can you please confirm that if you let MM running after the edits that the memory decreases in minute or two?
i.e. let the DbgView running 3 minutes after edits without touching MM and save the log.

Ludek

2024-09-12 18:22

developer   ~0076915

Last edited: 2024-09-12 18:23

I am still not getting the same behaviour as yours and the mem does not increase so much in my case..

Could you please do two additional tests for me:
1) Check whether the memory increases even if you are not adding the artwork
2) Check whether the memory increases when you launch the properties using Ctrl+Alt+P shortcut (not via menu)

Ludek

2024-09-13 11:32

developer   ~0076927

Could you please test whether you can replicate with 3052 after the fix of 0021200 ?

lowlander

2024-09-14 23:50

developer   ~0076963

It still seems to leak on 3053. New logs, etc. added.

Ludek

2024-09-15 13:11

developer   ~0076970

Last edited: 2024-09-15 13:14

OK, seeing that during the editing from 4:23 PM to 4:42 PM the memory stays still about 300 MB (305 MB - 386 MB)

The issue is that during the first 3 minutes (from 4:20 PM to 4:23 PM) it grown to 300 MB, and then never gone under 300 MB again..

Ludek

2024-09-15 18:50

developer   ~0076971

Last edited: 2024-09-15 19:14

Fixed in 3054

There was a general issue with garbage collector (was not called in some cases and thus kept no longer used memory)

Nevertheless with your MM5.DB I was unable to go under 300 MB anyway..