View Issue Details

IDProjectCategoryView StatusLast Update
0015914MMW 5FileMonitor / Find Missingpublic2019-08-30 14:12
Reporterrusty Assigned To 
PriorityimmediateSeveritycrashReproducibilitysometimes
Status closedResolutionfixed 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0015914: Selection of tracks in Artist:AristName --> Not all close query events are finished
Description1 Select all tracks in Home > Artist:Simon And Garfunkel
2 Right-click on the selection

--> MM freezes with "Not all close query events are finished"
Log ID: 46CB85A7
Debug log attached.

note: This is on my new machine. Also I noticed that when I was looking at the tracks in this view, they were all missing artwork; I wonder if it's somehow related to artwork caching.
TagsNo tags attached.
Attached Files
Fixed in build2194

Relationships

related to 0014574 closedpetr Issues in Locations node: 'loading' endlessly, duplicate images, and errors 
related to 0014579 closedpetr 'Loading...' appears endlessly 

Activities

rusty

2019-08-29 01:41

administrator   ~0054439

I'm seeing related behavior in build 2193: Endless Loading / Reading files:

Navigate to Music > Location > D:/My Documents/Temp/dl (all)
--> Loading... and Reading Files appear indefinitely
Close MM
--> crashlog (ID: 46CBD12E)
After sending the log, error appeared 'Not all close query events...'
Debug log attached

Ludek

2019-08-29 10:11

developer   ~0054450

Last edited: 2019-08-29 10:15

I cannot replicate, but based on the log ( Simon-Garfunkel_Not-all-close-query-events-are-finished_crash.7z ) the blocking task (and the longest running) task is
TASK 0 runs for 93844 ms, thread[14356], stack: TSharedUIList<T>.processTableUpdate, list type: tracklist, count: 98, created ago: 2907ms, stack: Callstack: Script: file:///helpers/artistDataSource.js ; Func: undefined ; Row: 180 ; Col: 45

There is a deadlock on SDLockWrite (thread 14356) -- based on 46CB85A7 , to find how this deadlock could happen.

EDIT: crash 46CBD12E is also the same deadlock on SDLockWrite lock.

Ludek

2019-08-29 11:06

developer   ~0054451

Last edited: 2019-08-29 11:07

Unfortunately from both 46CB85A7 and 46CBD12E it is not seen which thread owns the write lock, probably because it was acquired 93 seconds before closing the app (and there were many other threads created and destroyed meanwhile).

I added more debug info (new assertion directly to the write lock):
"Thread X owns write lock for 3 seconds!!! - possible deadlock"

This assert will pop-up for Rusty in the new build.
Assigned to Petr to compile new build for Rusty so that we can see more.

rusty

2019-08-29 12:28

administrator   ~0054452

I was able to replicate the problem with build 2193-A (custom build):
1 Switched between several directories at Music > Location > D:/My Documents/Temp/dl (all)
--> MM froze. Crashlog ID: 0763A44E
--> Dialog: Thread [0] owns write lock for 3 seconds!!!
Force closed MM

Debug log attached

Ludek

2019-08-29 14:11

developer   ~0054455

Last edited: 2019-08-29 14:11

I have made a mistake in the new debug code and the "Thread [0] owns write lock for 3 seconds!!!" is actually a false positive assertion.
Petr is creating a new build to test.

Ludek

2019-08-29 19:41

developer   ~0054462

Last edited: 2019-08-29 19:44

Note that I have found a way how to replicate similar kind of the deadlock on my PC, and generated 46CBDEC7

My steps were:
1) Focus a large auto-playlists with artwork column visible -- i.e. List (by Album) view
2) restart MM5
3) Immediatelly after start switch to another large auto-playist
4) Close MM5

Going to look into it further tomorrow....

rusty

2019-08-29 21:29

administrator   ~0054463

It took longer, but I was able to replicate a variant of the problem with build 2193-B.
I switched between various (Location) nodes, auto-tagged some tracks, and then when I initiated a Global Search 'Loading...' appeared endlessly. Closing MM5 -->
Not all close query events are finished
Crashlog: 46CB422C
Debug log attached.

rusty

2019-08-29 21:46

administrator   ~0054465

I observed a similar issue as follows:
1 Open auto-playlist (80's+90's music 300 tracks) and click edit
2 Modify the parameters (change to 400 tracks, change sort order)
--> Reading.... appears endlessly

However, upon closing MM, a crashlog isn't generated. Here's the debug log in case it's helpful.

rusty

2019-08-29 21:50

administrator   ~0054466

Upon restarting MM5 and attempting to edit the playlist again
--> Crashlog OF238F8F
(MM is frozen and must be force-terminated)

rusty

2019-08-30 04:22

administrator   ~0054468

Last edited: 2019-08-30 04:29

I'm also able to replicate the 'endless hourglass' problem (at least I think it's the same issue) by clicking the Audiobooks node in the Sync list (after I'd checked items in Music>Artists):
Crashlog 9F2E5ED6
This issue occurs consistently (i.e. just clicking on the 'audiobooks' node triggers an Endless hourglass).


Note also: Global Searches (and possibly other triggers) can trigger the problem as well in build 2192 (surprising since I hadn't noticed it earlier...which makes me think that perhaps there's a change in my MM5 environment [e.g. the DB/Thumbnails/config/etc.] that's related to the problem).

rusty

2019-08-30 04:43

administrator   ~0054469

Wifi Sync also triggered and endless hourglass (during the metadata update phase of the sync) --> crash
Crashlog: 875B657C

Ludek

2019-08-30 09:48

developer   ~0054472

Last edited: 2019-08-30 10:18

I added much better debug info and now I finally understand this lock crossing issue. Working on a fix...

Assigned to Petr (as it is his code) and details discussed over IM...

petr

2019-08-30 10:56

developer   ~0054473

Fixed

rusty

2019-08-30 14:12

administrator   ~0054476

I've done limited testing on this in 2194, but it seems to be resolved.