Crash/assertion failure playing to end of score

• May 29, 2019 - 02:38
Reported version
3.1
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
duplicate
Regression
Yes
Workaround
No
Project

Not sure this crashes in a release build, but the debug build reports it fairly reliably. Just play the last few measures of the attached score, if it does fail the first time, it should the second or third.

Assertion failure is at the beginning of Score::setPos():

Q_ASSERT(tick <= lastMeasure()->endTick());

If I alter the code to let me set a breakpoint there, I see "tick" seems to be pretty strange, it's 77441/640. That's not really what I'd expect a valid fraction to look like, but beyond that, it's also just beyond the actual end of the score, which is 121 (77440/640).

Doesn't actually crash in release for me, but if we're setting a bad value based on this, maybe it leads to corruption later?

Attachment Size
Soon It's Gonna Rain.mscz 145.65 KB

Comments

I had this happening with another score. (Also on 3.1, openSUSE 15.0, built against Qt 5.12.3.) Would it help you to have my score?

Reported version 3.1 3.3

This is happening for me as well on the release version of MuseScore 3.3 on openSuSE tumbleweed.

no segment for tick 76800 (start search at 76800 (measure 74880))
ASSERT: "tick <= lastMeasure()->endTick()" in file /home/abuild/rpmbuild/BUILD/MuseScore-3.3/libmscore/score.cpp, line 3787

Reported version 3.3 3.1

It really should not happen in real release version, as there those asserts evaluate to nothing at compile time.
So whoever build that version for OpenSuse, screwed it up there, leaving on debug mode.