Crash deleting key signature with linked staff

• Mar 16, 2015 - 23:46
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Ubuntu 14.04, GIT commit: f953fe7

Originally reported in http://musescore.org/en/node/51086

1) new score for guitar with two linked staves (standard + tab or standard + standard_
2) add key signature to measure 2
3) delete key signature

Result: crash

Running under debug the crash is actually an assertion failure here:

https://github.com/musescore/MuseScore/blob/f953fe7ef017e2e2eed5d7aea92…

track is 4, but _elist[4] is 0. I'm guessing removing the key signature from first staff removed it from the linked staff as well because removing a keysig always removes from *all* staves, so there is nothing left to remove here. Meaning we could prevent the crash by skipping linked staves in the same score when deleting keysigs, perhaps.

Comments

• Mar 17, 2015 - 02:11

This issue occurs between October 11 (no nightly on sunday 12) and more likely on October 13

- This Nigthly is correct: a7dab0a

- I receive a crash with this one: 386775a

There is a few commits in beginning October 13. But, as first idea, this commit for example might be a good candidate maybe? https://github.com/musescore/MuseScore/commit/609bee3ff7aaea7dfac76df02…
To fix. #29826: Deleting a key signature does not delete it from all staves of score

An other (less convinced!) : https://github.com/musescore/MuseScore/commit/5b6af43bee32afc11310c31b0…

Reply

• Mar 17, 2015 - 02:26

Thanks for the analysis! Meanwhile, I've learned a lot too. The problem has to do with the fact that clicking one key signature selects them both, and that is the change you found. But I believe even before that change, it would crash if you selected them both yourself (for instance, if you used ctrl+click to select them both).

Here is my analysis so far:

When we go to delete the key signature, both key signatures are actually selected. This is normal behavior when selecting a single key signature - all key signatures in the segment are automatically selected (as per the change identified by cadiz1 above!).

So in cmdDeleteSelection(), we try to delete both key signatures in turn, via deleteItem(). However, deleting the first one actually deletes them both, because they are linked. Even the segment they belong to is deleted. So when we return to cmdDeleteSelection(), we really should be done. However, now we try to delete the other key signature, even though both are already deleted as has the segment they belonged to.

From this analysis, it seems like we should be able to crash any time we select an item and its link at the same time then press Delete, but in reality, we usually don't. For example, if you place a fermata on a note in a linekd staff, then select both of the linked fermatas and press Delete, we get a console messge from the parent of the fermata - "ChordRest::remove(): articulation not found". Twice, because in fact both the fermatas were removed the first time, and we're trying to remove them both again. So life goes on.

I would say we can catch the key signature the same way, but I don't think we can. The key signature's parent is the segment, and the segment containing has already been removed. I'm not sure it has literally been deleted, but I would rather not trust it.

BTW, I get a do similar crash if I insert a breath into a linked staff then select both linked breaths and hit Delete. Probably similar reason - the breath segment was deleted after deleting the first breath and its link.

Reply

• Mar 17, 2015 - 03:10

I have a fix I am testing. It's just a matter of keeping track of linked elements in cmdDeleteSelection() to avoid deleting the same element twice. Should have PR soon.

Reply

• Mar 17, 2015 - 03:57

Wow! Yes, you are right.
I did my tests in comment #3 with a standard staff + a linked Tab staff (so: without other displayed key signature)
And indeed, by testing with two standard linked staves, and then select the key signatures both (and delete), I find this bug while constantly throughout the last months until May 19!
Good idea to have released the RC before the final version :)

Reply