View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015914 | MMW 5 | FileMonitor / Find Missing | public | 2019-08-28 19:02 | 2019-08-30 14:12 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015914: Selection of tracks in Artist:AristName --> Not all close query events are finished | ||||
| Description | 1 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. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2194 | ||||
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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.... |
|
|
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. |
|
|
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. |
|
|
Upon restarting MM5 and attempting to edit the playlist again --> Crashlog OF238F8F (MM is frozen and must be force-terminated) |
|
|
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). |
|
|
Wifi Sync also triggered and endless hourglass (during the metadata update phase of the sync) --> crash Crashlog: 875B657C |
|
|
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... |
|
|
Fixed |
|
|
I've done limited testing on this in 2194, but it seems to be resolved. |
