Regression: inability to change a clef inside a system leads to crash

• Oct 30, 2016 - 11:14
Reported version
S2 - Critical

GIT commit 292a8d9 / Windows7

1) "My First Score"
2) Drag and drop the bass clef in measure 3 (hightlighted)

Expected result:
expect clef.jpg
Current result: the bass clef is not added (or, it jumps directly to the second system?)
current result.jpg
Same for other systems of course.

And also, by other means: ie by hightlighting the whole rest of the measure. Or, by double-click (ditto by select first the measure, or the rest)

Last observation: by adding a clef in the first measure of the second system (and followings), the courtesy clef is not a the good size (ie the same size than the main clef)


I see the opposite effect, opening a 2.0 score that didn't have such a mid measure/staff clef now has one, not sure whether that is related.
And adding a clef to "my first score" here causes a crash (maybe because it is a DEBUG build?), due to a failed assertion:

Fatal: ASSERT: "e == 0 || e->type() == Element::Type::CLEF" in file ...\MuseScore\libmscore\element.h, line 813 (:0, )

Likely introduced by excatly that commit with deals with 'cleanup drag&drop'

Applying a clef to a note or rest (rather than to a measure) does work, but always does apply to the 1st note/rest rather than the one it got dropped on.

When applying a clef to a a full measure rest via double click, it crashed, again with a failed assertion, but a different one:
Fatal: ASSERT failure in QVector::operator[]: "index out of range", file C:/Qt/5.6/mingw49_32/include/QtCore/qvector.h, line 427 (:0, )

Me too I can get crashes. But really very instable (not systematically, and in different scenarios). The behavior was worse, more crashes, or/and (according, too, different things) huge space created in the measure when adding a clef, with the previous nightly: ea88600
This issue, at least, the main problem (no clef added to a measure "inside" a system), is not related to the current nightly: 292a8d9
Rather former/former, from what I see by now. I go to check with more focus.

Title Regression: inability to change a clef inside a system Regression: inability to change a clef inside a system leads to crash

Ah, thanks.
But it is perhaps useful to report the result of my observation, for reference (this will prevent to search again, if necessary).
So, I was about to say that the first change took place on last June, 3.
- With this nightly: 41b89ae, result as expected:
1) 41b 3 juin.jpg
But not with this one (clef added, but not to the next system): a41b109
2) a41 2 juin.jpg
- Then the second change came on October 25, with this nightly: f7d9650 and the result described initially (no clef in the expected location, but jumps to the second system)
3) 25 octobre.jpg