|
|
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) |
|
|
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) |
|
|
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-4.png (155,556 bytes) image-5.png (154,441 bytes) image-6.png (154,933 bytes) image-7.png (157,709 bytes) image-8.png (158,585 bytes) |
|
|
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. |
|
|
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) |
|
|
Could you please test whether you can replicate with 3052 after the fix of 0021200 ? |
|
|
It still seems to leak on 3053. New logs, etc. added. |
|
|
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.. |
|
|
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.. |
|
|
Verified 3054 |
|
|
It still seems to leak on 3054. New logs, etc. added. |
|
|
The memory is growing mainly because of redundant Window objects (that takes 49% of retained memory), both in mine and yours Snapshots there are finally 10x Window objects (although there should be only one).. i.e. re-opening Properties dialog adds another Window object for some reason (that is not garbage collected).. Assigned to Petr to look into it.. image-9.png (95,335 bytes) |
|
|
But even newly opened card in Chrome has Window object there 25x So hard to guess whether we can do something about this, and because every card in Chrome is separated process then Google probably doesn't take care much about used memory.. :-( image-10.png (48,865 bytes) |
|
|
More info about multiple Window objects: https://stackoverflow.com/questions/75301974/why-there-are-multiple-window-objects-in-heap-snapshot |
- Anonymous
