View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017145 | MMW 5 | General | public | 2020-11-29 02:35 | 2020-12-03 22:18 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0017145: Crash on close | ||||
| Description | Build 2275 was often crashing on close after MM was left running for a long time. | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=97837 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2278 | ||||
|
|
I can confirm (from the Rusty's ELF) that it was a freeze in UPnP.dll on closing (took more than 10 seconds so resulted in the assertion/crash) I enabled full logging in UPnP.dll on closing for the next build to find more, it is quite verbose though (thousand of lines in my case), but probably not a big deal when it is just on closing. I can disable the logging again once we find the reason for the freeze. So resolved for testing in 2277 and to generate new crash logs. |
|
|
Note: when I update my existing MediaMonkey portable installation and run it, this error doesn't occur. When I do a clean portable install, it occurs consistently. |
|
|
Tested 2277. Note that the bug does _not_ require that MM be running for a long time (in contrast to my original report where I happened to notice the issue after MM was running for a long time). Also, I want to re-iterate that this is only occurring on a clean installation. 1) Installed MM (clean-Portable). 1 Ran MM, with default wizard settings, scanned directories (added a couple) --> Scan proceeded 2 Closed MM after all activity ended --> Crash on close. - Debug Log and crashlog saved 2) 1 Ran MM 2 Closed it after startup activity completed --> crashlog 1 (MediaMonkeyEngine.el appear in the Eurekalog\Bug Reports directory) --> crashlog 2 (MediaMonkeyEngine.el updated and was deleted as soon as I clicked send logs @12:16am) - Debug Log saved / Crashlog sent? 3) 1 Ran MM --> Endless hourglass (status bar shows: 'Loading') 2 Force terminated MM after about 10 minutes of waiting - Debug Log saved 4) 1 Ran MM 2 Closed it after startup activity completed --> crashlog 1 (MediaMonkeyEngine.el appear in the Eurekalog\Bug Reports directory. Immediately renamed it, and then clicked 'Send logs') --> MediaMonkeyEngine.el updated and I saved it as well) - Debug Log saved and crashlogs saved Cases 1, 2, and 4 are typical of the behavior I've been seeing when I do a clean install of recent builds. Case 3 is slightly different but reminds me of behavior we'd seen in earlier builds of endless 'loading' (e.g. 0014579 / 0014574) Lastly the behavior that I observed in case 2 seems to be a Eurekalog bug. It appears that if multiple crashlogs are generated, that sending the second one causes the crashlog to be deleted! I'm able to replicate this consistently but am not sure if it's a bug. Please confirm. Debug/Crashlogs posted to ftp EDIT: I've discovered the cause of the bug. It only occurs on a clean install of MM IFF a CD is in the CD drive prior to MMW5 being started!! The difference between my 'regular' portable installation and the 'clean' portable installation is that the regular one already has metadata associated with the inserted disk. e.g. my regular copy shows E:\[Depeche Mode - Violator], the clean install shows E:\[Audio CD]. Also when I run the clean install, it spins up the CD drive, but when I run my regular install, it doesn't. |
|
|
I haven't been able to replicate using the clean portable install and an audio CD inserted. But in your crash logs I see that it is waiting endlessly for a thread that no longer exists! The thread probably somehow failed to unregister properly. From the debug log I don't see the reason and also don't see the thread ID to be able to analyze this deeper. Please replace your current MediaMonkeyEngine.exe from 2277 by this one: https://www.dropbox.com/t/pbrVO4ZxWft3vDSv and generate new debug log and new crash log (that should give me the info). Re: Eureka: Yes, it is currently set to always use the last log (and not pipe them) when sending. But there is a constant for this in Eureka settings, I wll ask Petr to set it to three -- so that also the last two logs that failed to send are send next time with the next log being sent. |
|
|
Assigned back to me, I've just reproduced something very similar, analyzing... |
|
|
Finally I've been able to consistently replicate the issue. Fixed in 2278 |
|
|
Verified 2278. |
