Crash when clicking on notehead during playback

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 believe it depends on the platform. Some platforms seems to be ok when we are clearing a QList when iterating it. Mac OSX is not.

Fixed in 118bb9308a

Could you share new logs please?
Now it can crash because of another problem.

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.

Maybe this is naive, but is there a use case for clicking notes during playback? Couldn't we simply disable this?

to rewind playback start to that note?

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.

Here is a change to disable the ability to change to any mode that could alter the score while still in playback mode:

https://github.com/musescore/MuseScore/pull/1603

Seems likely to fix any problems relating to this general issue. And now that I've played around with this some, I agree that the ability to seek by clicking is too cool to want to give up :-)

Fixed in 7dcf924838

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.

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.