crash in pasteChordRest when tick2measure returns null
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.
Comments
When running in release mode, the crash doesn't happen until it's in the undo handler. The bug is not in the undo handler, though.
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
That MusicXML file doesn't seem to have set any time signature, but does seem to be in 3/4 with a 3/8 pickup measure
Furthermore the MusicXML file seems corrupt:
![4.png]( "4.png")
Measure 18, Staff 1 incomplete. Expected: 3/4; Found: 58/72
And once a score is corrupt, anything can happen...
Creator of that bogus MusicXML file apparently is Audiveris 5.1.0, so please report that there
In reply to Furthermore the MusicXML… 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.
No. Save after import, close, reopen -> corrupt.
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.
Might be an idea to invoke the sanity check after MusicXML import (or after any import), not only when opening MuseScore files