View Issue Details

IDProjectCategoryView StatusLast Update
0017547MediaMonkey 5Playbackpublic2021-05-03 13:35
Reporterrusty Assigned To 
PriorityurgentSeveritycrashReproducibilityrandom
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0.1Fixed in Version5.0 
Summary0017547: Playing mm for hours (--> crash 875B000 : fixed) --> increased memory utilization
DescriptionMediaMonkey was running for about 25 hours, but not doing anything. On close, it 'black-screened' with the following crashlog: 875B000
Additional InformationCPU/Memory utilization issues reported at https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=98780
TagsNo tags attached.
Fixed in build2334

Relationships

related to 0017655 resolvedLudek Crash on close after running for awhile (crashlog ID 8F658A3F ) 
related to 0014592 resolvedpetr Upgrade to the latest Chromium 
related to 0017755 closedLudek Memory leak while casting to DLNA client 
related to 0017772 feedbackrusty Significant memory leak while browsing content 

Activities

Ludek

2021-02-14 22:02

developer   ~0061927

Fixed in 2311

peke

2021-02-18 22:27

developer   ~0061997

Verified 2211

MM5 was started for 34h and closed with no issues,

TEST Note: I've done few Deep sleep functions that my MB support and it also came back fully working. Also tested WOL function to restore PC from Deep sleep after MMA sync initiates (No timeout) System woke within 3 seconds and sync started.

rusty

2021-02-21 00:31

administrator   ~0062057

This occurred again for me with 2313 (though no crashlog resulted). Retesting.

rusty

2021-02-23 21:43

administrator   ~0062122

Unable to replicate with 2315.

drakinite

2021-02-24 21:22

developer   ~0062129

I also haven't experienced such crashes since 2315

rusty

2021-02-27 23:50

administrator   ~0062170

A variant of this just occurred for me with build 2316. Run MM and play music. Then stop playback. Leave MM5 running and leave PC for 25 hours (pc isn't set to go to sleep--just to require sign-in)
--> On sign-in, MM is frozen!

Note:
- MM is frozen on Music > Genres > Acoustic Rock > [List]
- NP list is loaded with 1107 files [List]
- Memory utilization seems normal

I'll try to replicate with dbgview running.

rusty

2021-03-07 00:22

administrator   ~0062278

I tested this again as follows:
1 Run MM
2 Initiate playback of 400 tracks
3 check status 26hrs later
--> UI responds normally but 1.3GB memory utilization!

Perhaps this could be an artifact of dbgview running, BUT the debug log is only 25MB so I suspect there is a memory leak. Debug log saved to ftp--hopefully it contains some useful info.

Ludek

2021-03-08 15:59

developer   ~0062286

Last edited: 2021-03-08 16:21

View 7 revisions

From the debug log I can cofirm that it started on values like:
(R) MemRAM: 234.8 Mb, MemPrivate: 214.5 Mb, MemVirtual: 608.2 Mb
and ended up with:
(R) MemRAM: 739.3 Mb, MemPrivate: 719.4 Mb, MemVirtual: 1.1 Gb
after 25 hours of playback.

The memory utilization grown slowly with files being played and in half of the process the utilization was:
MemRAM: 536.7 Mb, MemPrivate: 507.0 Mb, MemVirtual: 946.7 Mb

It seems that with every lyrics lookup it jumped up a bit, but there could be a leak also in playback itself, almost all tracks have been played via in_mfaudio.dll plugin and not all have been searched for lyrics (while the memory utilization was still growing)

So we need to ensure that there isn't a leak either in (or both):
1) in_mfaudio.dll plugin
2) Lyrics lookup
3) Note that there were also several YouTube tracks played, but only the first one bumped memory up +50 MB, so I suppose it was because of caching YouTube playback window/process ?

michal

2021-03-09 19:23

developer   ~0062317

1) I analyzed all allocations and releases and everything is in pairs and called during playback as it should, could not find any leak.
2) lyrics lookup remembers results from the last hour, if not saved to tag, but it should not be such problem
3) yes, it is caused by Google player, we could not affect this.

Please try to compare the results of longer playback of the same files when DbgView is closed and when is opened. I think it should be noticeable after 1-2 hours, whether it makes difference.

Ludek

2021-03-17 12:36

developer   ~0062473

Last edited: 2021-03-17 12:41

View 2 revisions

The crash on close related to UPnP is already fixed as 0017655

As for the leaking, it might be the player visualizer leaking the memory, namely this closure when comparing the snapshots:
https://www.dropbox.com/s/o9oade3uqtyzk3j/screenshot%202021-03-17%2013.33.38.png?dl=0
when double-clicking the closure then we can see that it is setTimeout in the queueRequest (mminit.js):
https://www.dropbox.com/s/qtydnsbrj1dfp9v/screenshot%202021-03-17%2013.35.51.png?dl=0

Michal, please verify.

michal

2021-03-17 13:43

developer   ~0062475

This was not leak, only garbage collector did not release everything yet. There does not seem to be any leak during playback in JS part of application.

rusty

2021-03-17 13:59

administrator   ~0062476

Another test. Left 2325 debug playing 17hrs with Preview and Player disabled (Main Panel:Home, Playing were all that was enabled).
--> Utilization grew from ~287MB --> ~437MB

MM Closed normally.

rusty

2021-03-18 14:06

administrator   ~0062506

Last edited: 2021-03-18 14:17

View 3 revisions

Michal indicated that MEMCHECKing does not show any leak in Delphi part, DevTools does not show any leak in Javascript part. This leaves chromium as the likely source, and as such it would need to be re-evaluated with an updated version of chromium.

Ludek

2021-04-13 21:33

developer   ~0062812

Last edited: 2021-04-13 21:42

View 2 revisions

Analyzing the log again I think that the reason for the memory leak could be the same as in 0017755
i.e. lekaing prepared queries.

Please re-test in 2334

rusty

2021-04-15 14:04

administrator   ~0062833

Last edited: 2021-04-15 19:37

View 3 revisions

Tested 2334 and this seems to be improved though there's still room for more improvement: after running MM5 and playing for 8 hours overnight, memory utilization grew from 240MB to 345MB.

Note: Local playback seems to leak more memory than DLNA ( 0017755 )

Ludek

2021-04-18 19:23

developer   ~0062872

Last edited: 2021-04-18 23:05

View 5 revisions

Strange, I don't see any leak when using local playback.

Tested 4 hours of playback, it started at 187 MB and sometimes it was above 220 MB, but after the 4 hours it was lowered to 184 MB (tracks still playing). So I don't think there is a leak related to playback.
Not sure what could be the difference, I tested with WASAPI ouput and lyrics auto-lookup disabled, main window was minimized.
For build 5.0.1.2400 added a debug output of allocated internal objects (created in delphi) that will be visible in debug log every minute (just like currently the utilized memory is seen in the debug log every minute).

EDIT: After 8 hours of playback it is 195 MB, so I definetely do not observe the leak in my environment.

Ludek

2021-04-19 22:48

developer   ~0062884

I don't think there is a leak while playing, but I found a _significant_ leak while browsing content -- fixed as 0017772

peke

2021-04-21 10:56

developer   ~0062901

Verified 2238

After 8h and scanning/refreshing UI and AA utilization was stable on 280MB from 230MB on start of MM.

TEST NOTE: UI was more responsive in 2338 than in 2336 about 30% (50-100ms) Faster on view refreshing and caching AA.