|
|
Fixed in 2170 |
|
|
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... |
|
|
56CBA9C7 isn't here, you probably meant 46CBA9C7 |
|
|
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 |
|
|
Test note: verify 0015579 and 0015465:0053107 as well |
|
|
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. |
|
|
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.... |
|
|
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. |
|
|
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. |
|
|
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 ? |
|
|
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. bug15592_build2171_memcheck_with_custom-exe.jpg (23,676 bytes) |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
Mass edit improvements done in 2173 |
|
|
Verified as non reproducible in 2173. but due the my availability of resources, it may slip. Close after second confirmation of fix |
|
|
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 |
|
|
fyi, still seeing this in 2174. |
|
|
There were several changes in area where it was crashed. Please retest in 2177. |
|
|
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. |
|
|
Unable to replicate in 2178. |
|
|
Verified 2178. |
|
|
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. |
|
|
Closing Not seeing this in a while. Tried to replicate on 2260 for a 30min by stressing tagging and interrupting it during background tagging. |
- Anonymous
