View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019441 | MMW 5 | Playback | public | 2022-10-07 22:06 | 2022-10-14 15:38 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0.4 | ||||
| Target Version | 5.0.4 | Fixed in Version | 5.0.4 | ||
| Summary | 0019441: File Monitor sometimes freezes (and MM then crashes after initiating playback) | ||||
| Description | While testing 0019395 and switching between different test xxx.js files, I fond that standard build 2669 would crash if I ran it and then immediately double-clicked the highlighted track in the Playing panel (usually while the file monitor was running). I'm no longer able to replicate the bug, so I wonder if it's a test artifact, but I submitted several crashlogs and generated debug logs that might reveal otherwise. MM crashlog: 2252AF1E with build 2669 MM crashlog: 22522151 with 2669 + updated .js file. Note: the file that was double-clicked isn't in the paths that are being monitored | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2672 | ||||
|
|
I experienced the issue again with build 2770. Crashlog 225286EE |
|
|
Upon further testing, I think that although double-clicking the playing track triggers the crash, the bug actually occurs earlier and is actually a bug in the file monitor in which it sometimes gets stuck on certain tracks. e.g. in the log below, MM was launched and I didn't double-click a playing track, but the file monitor got stuck on a 'German Arias........flac' track (log shows 'We are still waiting for read lock!!! , starving: 0, Info: has writer: 1' endlessly. At that point, double-clicking a track in the Playing panel triggers the crash, but apparently the problem occurs long before playback was initiated (i.e. the bug is in the file monitor, but playback triggers the crash once the bug has occurred). Note: the issue occurs maybe 1/10 times. The only reason I noticed it now is because I was repeatedly testing 0019395 which involved restarting MM over and over and over. Strangely, the bug seems to occur in 'spurts' i.e. it doesn't occur for long periods of time, but then will occur several times in a row. |
|
|
Based on the freeze log 225286EE it is crossing lock issue/regression related to recent Michal's changes in TPlaylistEntries.modifyAsync Details discussed directly with Michal over IM... |
|
|
Fixed in build 2671. |
|
|
I'm still experiencing crash 2252AF1E with build 2671 (the frequency of crashes seems to be a bit less than before now only about 1/15 tries). Note: In this case the file monitor didn't appear to freeze before the bug occurred. |
|
|
Added new assertion into build 2672 that will show more once Rusty is able to replicate this issue again (he is unable ATM) |
|
|
Most probably fixed the cause in 2672. To be confirmed by Rusty. |
|
|
Verified 2672. |
