Crash when clicking on notehead during playback

• Sep 11, 2014 - 13:10
Reported version
2.2
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S1 - Blocker
Reproducibility
Randomly
Status
closed
Regression
No
Workaround
No
Project

I had approximately five scores open. One was playing (a band score) and I clicked on a note that was a few bars ahead.

Result: Crash.

Note: See attached log.

Using MuseScore 2.0 Nightly Build 1479442 - Mac 10.7.5.


Comments

It's due to the fact that we are acting on the midi event list from two threads...

In the audio thread, processMessages() calls setPos() which calls updateSynthesizerState() and this function will go through the event.

In the UI thread, probably the click (?), made a call to seq::start() which calls collectEvents(), which will clear the event list we are iterating in the othe thread...

It seems that Mac OSX is particularly sensible of this type of things... the crashes we have in 1.3 on mavericks are due to the same programming error.

Can't reproduce. I try clicking on the note that a few measures ahead while playing. But I am just getting a seek.
Commit 05bb829, KUbuntu 13.04.
1. Maybe I need to do some additional steps?
2. Had you some dialogue windows opened (Mixer, Synthesizer, etc)?
3. Could you please share your score you are getting a crash with?

I think I've managed to reproduce this.

I was playing a score and double-clicking on rests - the Play button had greyed out. After sorting the latter, I resumed playback, clicked elsewhere repeatedly and it crashed.

Does this help?

Using MuseScore 2.0 Nightly Build 3855d63 - Mac 10.7.5.

Now it crashes again in Ms::Seq::updateSynthesizerState(int, int), but now on a new line: when touching Ms::EventMap::EventMap(...). Perhaps on this line.

Here's steps to reproduce from chenlung:
"1. Play.
2. Double-click on bar rest of bar 4 repeatedly, until playback button becomes unavailable.
3. Click on score.
4. 'Play'.
5. Repeat step 2."

When I try to make it I am getting a message box "Command play not valid in current state" on step 2 (double-clicking on a rest at measure 4 while playback).
Seems like MuseScore tries to toggle edit mode.
No crash in Linux, revision f4b9318.

In the same score used for the screencast, I reproduced using these steps:

1. 'Play'.
2. Double-click on bar rest of bar 4 repeatedly, until playback button becomes unavailable.
3. Click on score.
4. 'Play'.
5. Repeat step 2.

Notes:

The greyed out playback button is seemingly because the score is in edit mode.

I couldn't reproduce when deleting all but the first five bars in 1.3 and opening in the 2.0 nightly.

It would be too bad if you removed this feature. It was a big improvement over the MS 1.3 with it's unending space-click-space procedure. This is one of the main reasons I switched to MS 2 actually.

Could you explain further? I'm still not understanding the actual use case for clicking a score during playback. You're playing the score, then at some point you change your mind and decide you'd rather listen to a different part of it that happens to still be visible on the screen, so clicking during playback saves you the trouble of having to stop and restart playback in order to change the playback location?

For a simple rewind back to start location, we already have the loop feature, which has the advantage of working even after the start location has scrolled offscreen. Is this a different use case?

You've explained it well enough "You're playing the score, then at some point you change your mind and decide you'd rather listen to a different part of it that happens to still be visible on the screen, so clicking during playback saves you the trouble of having to stop and restart playback in order to change the playback location". Exactly. A loop feature is for... looping, so it's a different use case by definition.

Oh, an example: After writing some code I debug it to find errors. In some point an exception is thrown. A good debugger should break, allow me to go back a few lines and execute them again, without having to terminate, set a breakpoint and eventually restart a program. Similarily, after writing a score I play it to find typos and spot a harmony error in some place. Then I click on a note before the place to hear it again. Then stop, correct a typo and go on.

Perhaps you are misunderstanding the issue, or I am misunderstanding the use case you are describing. Sure, I get the need to lsiten to playback and then fix an error. but that was already possible and quite easy in 1l3, and still possible and easy in 2.0, and in no way requires the ability to click in the score *during* playback. Indeed, if your intent is to fix the error, you *have* to stop playback - you can't fix errors during playback. What am I missing?

The fact is that I use this feature quite often and I'm sure there are other users who like it as well. I can think of other use cases, e.g. a playback cursor (which isn't visible until playback starts) was too far and I quickly move it to another place. It's all about convenience. This functionality is not critical and can be removed if it's necessary (although I'd call it amputation). This is all I have to say.

I'm looking at this and from what I am understanding, it appears the original bug is fixed, and any crash that remains is the result of what could only be described as a concerted attack (repeatedly double clicking something in hopes of timing it just right so you are able to succeed in putting MuseScore into Edit mode while the score is still playing bacl), and that if you succeed in that, it might then also be possible to induce a crash (although I have so far failed).

If this is the case, I think this crash could probably be reduced in priority from critiical - I'd even argue for "minor". But it could probably also presumably be fixed simply by adding code to specifically disallow entering Edit mode during playback. I'm surprised it's possible as it is, but I guess maybe there is a window of opportunity while the cursor is being redrawn or something that you are able to trigger events.

Status (old) active needs info

Ok, then please post the specific score and specific instructions to reproduce, and in this case, since it seems unique to your system, the crash log would probably be helpful. It's most
likely yet an another bug, unrelated to either of the first two that have been fixed.

I still can't get a crash, but I can verify that unfortunately, my fix does not prevent MuseScore from entering Edit mode if you attack it hard enough. What happens is at some point if you double click long enough / fast enough, MuseScore::changeState() gets called with a val of STATE_NORMAL, so you are placed into normal mode, and the next double click after that will succeed in putting you into edit mode. I can't very well have changeState() prevent a change from play to normal modes - otherwise you'd never be able to stop playack. So this approach seems dead in the water. I am trying to understand how changeState() is being call with STATE_NORMAL, but the answer to that seems locked up in QStateMachine.

Still, I'm downgrading the severity of this, and am strongly downgrading it still further. I just can't see anyone repeatedly double clicking while playing a score, and given that even then, the crash seems seems to be Mac-only at best.

Title Clicking on a note during playback causes crash Crash when clicking on notehead during playback
Reported version 2.2

This report was filed years ago, but I maybe encountering something similar now, except it is changing the sound. These are approximate steps (refinement likely required):

  1. Open attached mscz (produced in 2.1).
  2. Open 'Mixer'.
  3. 'Play'.
  4. Change sound (e.g. to Electric Piano) at bar 3.
  5. Click on a notehead before this bar.

Result: Crash.

Notes: It's not easy to reproduce, but in trying there were different logs (see attached .zip file); I hope they are helpful.

Using MuseScore 2.2 Nightly Build 97433e4 - Mac 10.11.6.

In reply to by chen lung

I wonder if this is a Mac-only bug (couldn't manage to reproduce on Windows 10, so far anyway), but I've attached both another score and a video. The nature of it probably means a developer environment is required to know the cause.

It might require a few tries of clicking the first bar rest and also the subsequent one on the top stave, and back again. Try re-opening the score after about 10 seconds if it doesn't happen.

I'm not a developer, but I'll try to work with someone in reproducing this. I should note though that, whilst it would be nice to have it fixed for 2.3, it's not essential.

Note: This only applies to series 2, it would seem (3.0 disables notehead clicking during playback).

Using MuseScore 2.3 Nightly Build 26036d0 - Mac 10.11.6.

Severity S3 - Major S1 - Blocker
Status active closed
Frequency Once
Priority P0 - Critical
Regression No
Reproducibility Randomly
Workaround No

It is not possible to enter edit mode with current master during playback. I could not crash MuseScore with the latest scenario, too. Feel free to fill separate issue if you have particular steps to reproduce.