Crash when creating part of score with multi-measure rests enabled

This issue occurs on November 20.

Between this Nigthly: 0a913fd
With result:

-an this one, with crash: 3e73dc5
With result:

Not easy the first time to determine the exact location. Both nightlies are close to each other in time. So, maybe here: https://github.com/musescore/MuseScore/commit/6c03319d5ca455d60da8cc64e…,

- or the same Nightly/commit mentionned above: https://github.com/musescore/MuseScore/commit/3e73dc586e142fd6fc8d3e493…

- or another neighbour commit?

Pinpointing which build was the first with a problem no easier if you compile MuseScore for yourselft - it's mostly just a matter of keeping enough builds around and testing them all :-)

Building for yourself - and running under the debugger - shows you where the crash occurred.

Sometimes the latter is good enough, but sometimes not, so knowing when the problem occurred is helpful.

Form what I can see in the debugger, the issue seems related to a few other recent issues with multimeasure rests. The code is trying to access information about a measure that belongs to a system that has not been laid out yet. Multimeasure rests are tricky things. Not sure exactly where things went wrong.

I cannot reproduce this lon linux in b9875a6ee4

I can always reproduce under Windows7 and in b9875a6

I can:

Create new score from Piano template,
enable multi measure rests
generate parts (doesn't make much sense with just one instrument, but should not crash)

Debug: staffY: staves 0: bad staffIdx 0, vbox 1 (...\MuseScore\libmscore\system.cpp:1077, qreal Ms::System::staffYpage(int) const)
Debug: System::staff(): bad index 0 (.../MuseScore/libmscore/system.h:133, Ms::SysStaff* Ms::System::staff(int) const)
Fatal: ASSERT failure in QList::operator[]: "index out of range", file C:/Qt/5.4/mingw491_32/include/QtCore/qlist.h, line 482 (:0, )

Fixed in 0891e572c5

Strange enough i can reproduce the crash now, no idea what changed.
Its fixed in 0891e572c5.
I hope it fixes the crash you see. Reopen if not.

confimed, it no longer crashes for me

of course, I didn't really assume otherwise ;-)

Confirmed too, no more crash here.

Automatically closed -- issue fixed for 2 weeks with no activity.