crash in pasteChordRest when tick2measure returns null

• Feb 14, 2021 - 21:45
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

To reproduce, load the attached document, select and copy it all, and then paste it into a separate document. Apparently, the mxl loader does not follow the same rules as the paste command, or the former has been set up to handle invalid timing where the latter has not. I'm okay with it dropping something during paste; that would be much better than crashing.

Attachment Size
4.mxl 10.48 KB
crash.png 201.41 KB

Comments

Not a crash, but a failed assertion (and these indeed don't happen in Release mode):
Fatal: ASSERT: "rtick2 > rtick1" in file ...\libmscore\sig.cpp, line 178

Furthermore the MusicXML file seems corrupt:
Measure 18, Staff 1 incomplete. Expected: 3/4; Found: 58/72
4.png
And once a score is corrupt, anything can happen...

In reply to by Jojo-Schmitz

"And once a score is corrupt, anything can happen..." -- whaaaat? If Musescore loads it, it takes responsibility for what happens thereafter. That's true in any program. They have to sanitize their input. Musescore can either refuse to load a corrupt document or load what it can from it and warn the user that some data was lost.

Yes, in theory, it would be good programs could gracefully handle all unexpected error conditions. The reality is otherwise, it's really close to impossible to write programs so robust that it's impossible to trip them up with invalid input. Some programs simply refuse to load corrupt file, so that's of course one way to avoid crashing later, but we would prefer to give users the flexibility to fix the corruptions. So while yes, it would be nice to somehow autocorrect corruptions, meanwhile, in practical terms, it is important to fix the corruption first before doing further editing.