View Issue Details

IDProjectCategoryView StatusLast Update
0019441MMW 5Playbackpublic2022-10-14 15:38
Reporterrusty Assigned To 
PriorityurgentSeveritycrashReproducibilitysometimes
Status closedResolutionreopened 
Product Version5.0.4 
Target Version5.0.4Fixed in Version5.0.4 
Summary0019441: File Monitor sometimes freezes (and MM then crashes after initiating playback)
DescriptionWhile 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
TagsNo tags attached.
Fixed in build2672

Relationships

related to 0019374 closedmichal Performance regression in 5.0.4.2662 when selecting track in Playing panel 
related to 0016052 closedmichal Sorting in Playing view causes crash - regression 
has duplicate 0019442 closedLudek Occasional AV on startup (possibly related to mouse events outside of MM) 

Activities

rusty

2022-10-08 23:39

administrator   ~0069706

I experienced the issue again with build 2770. Crashlog 225286EE

rusty

2022-10-08 23:52

administrator   ~0069707

Last edited: 2022-10-09 00:12

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.

Ludek

2022-10-10 13:44

developer   ~0069745

Last edited: 2022-10-10 16:18

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...

michal

2022-10-10 16:16

developer   ~0069748

Fixed in build 2671.

rusty

2022-10-12 20:07

administrator   ~0069770

Last edited: 2022-10-12 20:14

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.

Ludek

2022-10-13 14:17

developer   ~0069793

Added new assertion into build 2672 that will show more once Rusty is able to replicate this issue again (he is unable ATM)

Ludek

2022-10-14 12:14

developer   ~0069799

Most probably fixed the cause in 2672.

To be confirmed by Rusty.

rusty

2022-10-14 15:38

administrator   ~0069806

Verified 2672.