View Issue Details

IDProjectCategoryView StatusLast Update
0015592MMW 5Tagging framework / input pluginspublic2020-11-09 18:36
Reporterrusty Assigned To 
PriorityurgentSeveritycrashReproducibilitysometimes
Status closedResolutionreopened 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0015592: Crash on close after tagging numerous tracks
DescriptionTested with 2169
1 Tag numerous tracks in the course of testing 0015563 (renaming Genres)
2 Play tracks while testing--> display error appears in which numerous copies of the playing track appear in the tracklist ( 0015591 )
3 Close MM --> MM fails to terminate
Crashlog: 370E02BC
Debug log attached

Note: I'm think that this is related to tagging since 0015591 hasn't caused crashes on multiple tests, and also because I experienced another non-reproducible crash (no log) on tagging multiple tracks in 2169.
TagsNo tags attached.
Attached Files
bug15592_build2173.7z (806,577 bytes)
Fixed in build2177

Relationships

related to 0014802 closedpetr Editing multiple tracks in My Folders --> crash 
related to 0015447 closedmichal Album View: Few UI tweaks 
has duplicate 0015623 closedrusty Click Music > Genres > GenreName-Popup > Album --> crash 
has duplicate 0015564 closedrusty Renaming Genres can result in crash 

Activities

Ludek

2019-04-15 12:52

developer   ~0053220

Fixed in 2170

rusty

2019-04-15 19:52

administrator   ~0053221

Last edited: 2019-04-15 20:22

In the course of testing this based on the usecase from 0015563 in build 2170, there still appear to be problems:
1 Navigate to Music > Genres > Alt. Rock
2 F2 and rename to 'Alternative rock' (another existing Genre)
--> The entry gets renamed, but then after a few seconds shows up again as 'Alt. Rock' (at no time does 'x files to be tagged' appear).
3 F2 again, and rename 'Alt. Rock' to 'Alternative rock'
--> The entry gets renamed, but then after a few seconds shows up again as 'Alt. Rock'. After a few more seconds '66 files to be tagged' appears, however, the tagging process is frozen.
4 Attempt to exit MM
--> MM is frozen but error log appears: 56CBA9C7

Note: I tested this out many times subsequently without replicating the problem. But then it occurred again apparently randomly upon renaming a genre with only a few (8) tracks, and I was able to capture the debug log (saved to ftp) and the error log: 46CBF9E0 . Testing further, but the only thing that might have been different on this test attempt was that rather than just right-clicking on the Genre, I expanded the Genre into a pop-up and then pressed F2. Testing further...

Ludek

2019-04-15 20:18

developer   ~0053222

56CBA9C7 isn't here, you probably meant 46CBA9C7

Ludek

2019-04-15 20:43

developer   ~0053223

Last edited: 2019-04-15 21:39

Based on the debug log (on FTP) there are some "frozen tasks" that filled the task queue (before issuing the app close) and prevents other tasks (related to closing) from being performed, to be found what are the "frozen tasks"

EDIT: The "frozen" tasks were issued during genre renaming.

=> Fixed in 2171

rusty

2019-04-16 19:29

administrator   ~0053256

Test note: verify 0015579 and 0015465:0053107 as well

rusty

2019-04-18 04:27

administrator   ~0053298

I'm still experiencing crashes/tagging anomalies with 2171. The problem seems to be triggered by renaming one Genre and then quickly renaming another before the first operation has triggered a screen refresh (doing this causes MM to try to rename the wrong Genre--one that may no longer exist since it was renamed in the first step). To better understand, see:
https://www.screencast.com/t/eHx3bNVtr0pl

CrashLog ID _was_ generated after waiting for awhile (in contrast to what I said in the video): 46CBDFCB

Debug log and Crashlog (in case it wasn't sent) posted to ftp.

Ludek

2019-04-18 10:04

developer   ~0053303

Last edited: 2019-04-18 10:36

46CBDFCB id not come here and DCB2926A (within Bug_15592_crashlog_and_debug_build_2171.7z) doesn't say much (and might belongs rather to 0015609 ) -- details in 0015609:0053300

Nevertheless I can replicate that the UI refresh isn't immediate, i.e. the old item remains in the list until all tracks of the given genre is renamed.

I cannot replicate the UI issues observed by you, but based on your debug log the task queue was overflowing again even 200 seconds before closing! This is causing the UI anomalies and not responsive UI (as newly queued tasks are not performed).
- at 268 seconds of the debug log there was 11 tasks in the queue
- at 375 seconds there was 71 tasks in queue and 61 tasks in low priority queue
- at 433 seconds there was 90 tasks in queue and 61 tasks in low priority queue

This was the reason why the "Not all close query events are finished" exception occurred at the time of closing.

From the log isn't clear what the tasks are, to be found. I am going to deeper analyze this and add more debug info....

Ludek

2019-04-18 10:53

developer   ~0053304

Last edited: 2019-04-18 10:55

Petr, could you please create a special build for Rusty with:
- MEMECHECKING enabled
- uncommented lines:
 OutputDebugString( PChar( 'BQ: new task callstack: '+task.GetCallerStack(1)));
 OutputDebugString( PChar( 'new task JS callstack: '+task.GetCallerStack(2)));

So that we can see what the tasks are?
Note that this build will be even slower, but should give us the needed info.

rusty

2019-04-18 18:16

administrator   ~0053306

Tested with 2171 memchecking and it took _much_ longer to replicate the bug with this build (I renamed about 20 Genres before the problem occurred), but it finally occurred when I started renaming Holiday (Holidays --> Holiday) or IndieX (IndieXX --> Indie) tracks.

Debug log 46CBB080 appeared to not be sent. Logs saved to ftp.

Ludek

2019-04-18 19:34

developer   ~0053308

Last edited: 2019-04-18 19:35

There is always "BQ: new task callstack:
[Unknown function at GetEurekaLog]

Any idea Petr? We would probably need to create a build without EUREKA and with MEMCHECKING to see the real callstack of the unknown tasks ?

rusty

2019-04-19 04:34

administrator   ~0053310

Tested 2171 debug with custom .exe's from Petr:
- MM still often edited a track other than the track that was selected (due to the UI refreshing after a previous track was edited)
- MM didn't crash as before, however, upon attempting to edit Genre 'Jazz, Instrumental'
--> Getting Data appeared in the status bar endlessly (see line 80358 of the log), and while this occurred, F2 fails and right-click fails. After about a couple of minutes the following error appeared "Application throw an exception Not all close events are finished !!" MM had to be force-terminated.
Debug log attached.

Tested 2171 debug memcheck with custom .exe's from Petr:
1 Rename a couple of Genres
2 At line 33500, Select Genre:Minimal and press F2
--> each time 'Memphis Soul' gets highlighted in the text box instead of the selected Genre (tried with Minimal; Minimal-tech; etc.)!
3 Renamed Memphis Soul --> Memphis Soul 2 --> Memphis Soul
--> MM didn't freeze. However, any attempt to edit any other Genre always resulted in Memphis Soul being edited! Also, right-click menu stopped working.
4 Switch to Music node --> Subnodes fail to load
5 Attempt to close MM --> Application throw an exception Not all close query events are finished... (see attached)
6 Attempt to close MM again --> Second exception appears (see attached)

Debug logs posted to ftp.

Ludek

2019-04-23 19:44

developer   ~0053333

Last edited: 2019-04-23 21:33

Based on the logs the tasks related to genre renaming (and related UI auto-update) are cumulated after renaming several genres. This tasks cumulation causes the subsequent UI issues and the "Not all close events finished" assertion.

From the logs it is still not clear whether and which tasks are in a deadlock or whether they are just long running and thus blocks the new async tasks from being performed.
I have made some optimizations and added more debug info (to build 2172). Further optimizations related to mass edit update are planned by Petr (as already discussed with him via IM).
Also, for some reason in the Rusty's logs the delphi tasks are still missing useful callstacks (was it really compiled with MEMCHECKING ?)

Assigned to Petr to implement the remaining optimizations.

rusty

2019-04-24 22:31

administrator   ~0053344

Attempted to replicated 15592 with 2172-memcheck build by renaming numerous genres. In most cases (ie. except where indicated below, it worked correctly), but for some reason, in some cases (see below) no tagging update indicator appeared in the status bar! Moreover, the last edit triggered a freeze:
1 Mellow --> "" : OK
2 Neu Deutsche Well --> "" : OK
3 New Jack swing --> "" : OK
4 New remantic --> "" : OK
5 New wave quirk --> New Wave : no tagging indicator!
6 None --> "" : OK
7 None/electronic/electro/daid guetta --> "" : OK
8 Novelty --> "" : No tagging indicator!
9 Northern soul --> Soul : No tagging indicator!
10 Ost --> OST : OK
11 Other --> "" --> 128 databasae entrieds to be updated (strange since afaik there weren't that many tracks in that category, but MM froze at 121 database entries to be updated!!
I waited for about 10 minutes, but MM did not crash (it just remained stuck at 121 database entries to be updated)
12 Clicked 'Close' --> 'Application throw an exception Unknown error message. Would you like to restart...'
13 Clicked 'Continue' --> MM turned into a white screen
Waited 10 minutes for a crashlog dialog but none appeared

Debug log saved to ftp

Ludek

2019-04-25 16:23

developer   ~0053368

Last edited: 2019-04-25 16:24

Task queue is OK in the last log from 2172, but there is:
Dump(String): "ProcessException failed: 8000FFFF, code: 31, message: Not enough memory resources are available to process this command.
- so this time it looks more like a memory leak -- or a problem with the custom build created by Petr?
Probably test with standard 2172 build?

Left assigned to Petr to implement the remaining optimizations.

petr

2019-04-26 22:11

developer   ~0053382

Mass edit improvements done in 2173

peke

2019-04-29 03:09

developer   ~0053392

Verified as non reproducible in 2173.

but due the my availability of resources, it may slip. Close after second confirmation of fix

rusty

2019-05-03 19:34

administrator   ~0053418

Tested 2173 and although the issue is much less common, it's still possible to trigger the problem. In the attached log you'll see:
- renaming many genres successfully
- at the end, renamed a Genre that contained several tracks (I think it was Rythm&Blues --> R&B)
- immediately selected the next Genre (I think it was Rnb) and pressed F2
--> view refreshed and MM showed the edit box as being associated with the _next_ genre after 'Rnb' (i.e. because Rythm&Blues was no longer there, MM caused the edit box to appear next to the wrong genre).
--> crash & white screen.

Log ID: C6C6657C

rusty

2019-05-09 23:42

administrator   ~0053455

fyi, still seeing this in 2174.

petr

2019-05-21 11:41

developer   ~0053596

There were several changes in area where it was crashed. Please retest in 2177.

rusty

2019-05-22 03:19

administrator   ~0053606

Last edited: 2019-05-22 03:21

fyi, I saw something similar in 2176. After making changes to numerous genres, MM stopped updating tags. e.g.
1 Edit GenreName in-place (including changing it to "")
--> DB and tag update appear in status bar
2 repeat step 1 numerous times
--> at a certain point tag updates stop being made.

Also, MM fails to terminate on Close once this happens.

rusty

2019-05-30 17:53

administrator   ~0053664

Unable to replicate in 2178.

rusty

2019-05-30 17:54

administrator   ~0053665

Verified 2178.

peke

2019-05-30 22:18

developer   ~0053672

Last edited: 2019-05-30 22:25

I got White Screen of Death using these steps:
Selected number of files -> Right Click -> Rating -> 2 Stars

No Error logs are shown after 15 minutes.

It happened twice after longer use of MM5, unable to replicate constantly.

peke

2020-07-12 13:22

developer   ~0058917

Closing Not seeing this in a while.

Tried to replicate on 2260 for a 30min by stressing tagging and interrupting it during background tagging.