View Issue Details

IDProjectCategoryView StatusLast Update
0015735MMW 5Tagging / organizing (properties / auto-tools)public2020-07-22 21:01
Reporterrusty Assigned To 
PriorityurgentSeveritycrashReproducibilitysometimes
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0015735: Crash on Mass Edit of Track Properties (build 2181)
Description1 Select 100 tracks
2 Empty and check all fields except Title and Artist
3 Click OK to accept the changes and initiate tagging
--> MM crashes (white screen)

Debug log: 249A1482

TagsNo tags attached.
Attached Files
Fixed in build2182

Relationships

related to 0015689 closedpetr Renaming Genre repeatedly causes loss of thumbnail 
related to 0013973 closedpetr Multi files edit properties can crash 

Activities

Ludek

2019-06-12 08:46

developer   ~0053799

Last edited: 2019-06-12 14:37

Based on the crash log there was "Out of memory" exception.
MediaMonkeyEngine.exe utilized more than 1.6 GB of memory and there were 24 of "TSharedUIList<T>.processTableUpdate" tasks in the task queue.
i.e. It seems that shared lists (or rather whole tracklists) are leaking ...

EDIT: Added more debug info to 2182 + fixed some code tweaks related to this issue

So please re-test in 2182

Ludek

2019-06-12 14:47

developer   ~0053800

Re-opened, there are still some leaking lists (based on the new debug info)...

rusty

2019-06-12 17:51

administrator   ~0053803

I've replicated the problem again with another crashlog (249AAE9E) in 2181.

I've been doing a lot of tests that involve tagging and it's generally stable. The only thing that I can think is common to the instances in which this crash occurs is that in both cases there were extended tags that were deleted. i.e. in Properties > Custom, select and delete extended tags and apply to all (in addition to all the other tags that were selected/deleted).

Test note: replicable with 'Now that's what I call music! 99' album.

Ludek

2019-06-13 11:31

developer   ~0053812

Last edited: 2019-06-13 16:04

ok, I am solving the lists leaking issues now, but it is true that the list leak isn't so huge.
So in your case I suspect that it leaks on a particular files when tagging the extended tags.
This time the MediaMonkeyEngine.exe utilized 1.7 GB of memory (based on 249AAE9E) when it crashed with the "out of memory" exception.

Could you please upload the 'Now that's what I call music! 99' album on FTP?

rusty

2019-06-13 16:36

administrator   ~0053813

I shared the album with you. Note, though: all tracks on that album are MP3s.

Ludek

2019-06-13 19:53

developer   ~0053816

Last edited: 2019-06-13 19:57

I am trying with the 'Now that's what I call music! 99' album and I cannot replicate the issue

These are the steps that I am using:
1) Scanned the album into library
2) Selected all 39 files > right-click > Properties > Custom tab
3) Removed extended tag "Upload: Hunter"
4) Clicked OK
=> 39 files tagged with no crash and no memory jump up (MME.exe utilizes still about 220 MB)

Could you describe your steps that leads to the 1.7 GB of memory utilization for the MME.exe process?
And if you can still replicate then please generate also the standard debug log (using DbgView) so that I can see all the history leading up to the "out of memory" issue.

rusty

2019-06-13 21:17

administrator   ~0053819

I'll resend the files in their original state in which I received them. Here's exactly how I replicated the problem.

https://www.youtube.com/watch?v=k25XT3huD18

Debug log and crashlog for this are on the ftp server.

Ludek

2019-06-14 08:19

developer   ~0053821

Last edited: 2019-06-14 09:01

You haven't re-sent the files so I still cannot replicate, but based on the logs the "Out of memory" always appear when removing cached thumb path from thumb cache.
It is a new code added by Petr in course of 0015689 (it is new in build 2179)
I am reviewing the code and will add more debug messages (in case I fail to find the code glitch)

EDIT: it seems that the key factors to replicate are:
- enabled the artwork column in the file listing (to see many same artworks for the individual tracks)
- remove the covers when mass editing

I am finally seeing where the problem lies and preparing the fix (was regression in 2179 by 0015689)...

Ludek

2019-06-14 09:00

developer   ~0053822

Fixed in 2182

peke

2019-06-22 02:23

developer   ~0053932

Verified 2183

Regression tested as like Ludek I can't replicate

peke

2020-07-22 21:01

developer   ~0059082

Unable to replicate in 2261

Closing.