adding a crescendo corrupts the file

• Apr 20, 2014 - 20:16
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

When I perform the following steps musescore crashes

1. load the attached file bethena-34,
2. open the palette to the Lines section
3. drag the crescendo 4 times to each of the 4 first notes of the 4 staffs at measure 48.
(thats the first of the 3 B-naturals in the top two staffs, the C in the 3rd staff and the D in the 4th staff).
4. save the file (actually save-as bethena-35).
5. press the x on the tab to close bethena-34
6. open bethena-35

At this point musescore crashes.

Which version am I using? 25bc366

Attachment Size
bethena-34.mscz 65.54 KB

Comments

• Apr 20, 2014 - 20:29

On further investigation, it seems I can add the crescendo to the top two staffs without problem, but thereafter adding it to the 3rd staff causes the problem.

Reply

• Apr 20, 2014 - 22:10

I can confirm the crash - thanks so much for getting this down to a nice reproducible case! Hopefully this will be the key to getting this solved.

I'm fighting the debugger big time right now - it's crashing more often than MuseScore itself is! - but what seems to be the case is that at some point after the second hairpin is added, the spanner map loses its mind. We end up with spanners with an id of -1 for which no endSpanner tag is written, or else a whole bunch of spurious endSpanner tags being written.

I've noticed the spurious endSpanner tags before while working on mtests, and I can reproduce that much in a simple case created from scratch with no parts generated. Score for four flutes. Places quarter notes in measure 4 for each staff. Add a single hairpin to the first quarter note on the first staff only, save as MSCX, look at result. I count 16 separate endSpanner tags for a single hairpin. That can't be right...

Reply

• Apr 23, 2014 - 12:35

I *think* I found where the problem possibly originates.
In libmscore/cmd.cpp, inside Score::cmdAddSpanner function, the track2 element of the spanner is not set; therefore it keeps the default -1 value.
When then the code actually inserts the spanner in the score at line 250 of cmd.cpp
undoAddElement(spanner); it uses the (not-yet-inserted) spanner's track2 property to determine the track2 for the to-be-inserted element (line 1027 and 1029 of libmscore/undo.cpp) .
The easiest solution could be to insert spanner->setTrack2(track); just after line 231 of cmd.cpp (spanner->setTrack(track);). I quickly tested this change and it seems to solve the crash; moreover, the spurious multiple endSpanner tags disappeared.
It does not however cure the case of already corrupted scores with missing endSpanner tags.

Another sidenote: inside Score::tick2measureMM function in libmscore/utils.cpp, at line 68, it returns the result of function lastMeasure() if tick=-1, while I think it should use instead lastMeasureMM() since we are possibly dealing with a final measure falling inside a MM rest.

Reply

• Apr 23, 2014 - 13:01

My recollection is we actually do depend on track2 == -1 for slurs that do not cross voices. There were a couple of bugs involving slurs in voices other than 1, and slurs between voices; both scores created in 2.0 and imported from 1.3. I remember MarkRS fixing them and working a little with him on the fix. I don't recall the details, but I do recall that being a component. Not saying there aren't other possibilities as well, but it will be oimportant to check that we don't break anything regarding slurs in vocie 2 or between 1 & 2 (also with 3, 4).

Reply

• Apr 23, 2014 - 13:44

I don't think slurs are inserted via the Score::cmdAddSpanner function, but I didn't look into fine details (I just put a breakpoint at that function and inserted a slur in the Promenade to check if it was hit).
The comment on the function states that it is used (only?) for: volte, ottave, trills, pedals, hairpins and textlines, but this comment can of course be outdated :-)
I can't image a situation in which these elements could have a track2 different from the initial track. We could use track2=track as default in the undoAddElement(spanner) when track2=-1, but in that case I don't know if special care was devoted to slurs (i.e. special handling of track2=-1 as you are suggesting).

I think the ability to change slurs' track2 is broken at the moment: it was Shift+arrow up/down on the last handle of the slur in edit mode, right?

Reply