Regression: Removing the content of measures after deletion of the time signature causes corruption/crash

• Apr 14, 2017 - 16:18
Reported version
3.0
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

2.1 R.C / Windows 10

First reported here: https://musescore.org/en/node/188046

1) "Untitled" score
2) Enter some notes in the first measures (not really necessary)
3) Delete the time signature
4) Remove the content (Del only, not Ctrl + Del) of the first measure, then the second, the third, etc.

Result: corruption which leads to crash
Sans titre .jpg

Comments

• Apr 14, 2017 - 16:42
Title Removing the content of measures after deletion of the time signature causes corruption/crash ⇒ Regression: Removing the content of measures after deletion of the time signature causes corruption/crash

Reply

• Apr 18, 2017 - 20:00

It seems the problem has do do with this part of the code specifically:

https://musescore.org/en/node/188456

We've already cleared the contents of the measure - deleting the full measure rests. Now we're looping through the measures adding new rests, stopping when we get to the end of selection, but we only do this if we can figure out what time signature we are in. Otherwise we keep skipping this section of the code.

Probably we need to execute this section of code anyhow. Maybe just checking ts before using it get the value of f, but setting f to 4/4 if ts is zero. Or maybe there is some other way we are supposed to know the time signature. Or maybe we borrow the code from cmdFullMeasureRest(), which seems to work fine (it doesn't rely on knowing the time signature)?

Reply

• Apr 19, 2017 - 17:12

Another corruption happens for similar reasons if the actual duration of the measure differs from what the time signature says. The same section of code highlighted above adds a rest of length equal to the time signature rather than what would actually be needed to fill the measure.

So I'm thinking, why mess with time signatures at all? Why not just use m->len()? Partial answer: we need to do the right thing in the presence of local time signatures. But probably there is a better way of dealing with all this.

Reply

• Apr 19, 2017 - 17:58

FWIW, in 2.0.3, it works OK if the actual duration differs from nominal, *or* if there is a local time signature involved. But if you have *both* going on, you also get corruption. Not just from this operation, other things fail too. See #189741: Corruption on operations involving measures with local time signature and modified actual duration, which I just filed.

I think for now we need to not support the combination of local time signature and altered actual durations, as there are probably lots of problems that would result. Apparently we detect this if the change in actual duration is already ion palce when we attempt to add the local time signature, but the reverse is not true.

Anyhow, I'll attempt a fix for the deletion issue that does work even if we have both situations going on, but I also think for now we should disable the change in actual duration if there is a local time signature.

Reply

• Jul 26, 2018 - 22:44
Status (old) closed ⇒ active
Status closed ⇒ active
Reported version 2.2 ⇒ 3.0

This was never merged for master so the problem still exists. Same fix hopefully applies, we'll see...

Reply