Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(I was already doing further work on this branch when the original PR was merged; if I need to repeat this work on a new branch, that's fine, it won't be hard)
The original bug in https://musescore.org/en/node/74881 had to do with drawing the selection rectangle after a paste into an mmrest. My initial fix addressed the symptom and successfully avoided the crash in that particular case but did not address the underlying cause and in testing I found other related issues, so I filed https://musescore.org/en/node/74946.
The first new commit here - the changes to Score::writeSegments() - fixes the most serious problems in 74946. If a selection ends in an mmrest and we do a "copy", we were actually copying the data all the way to the end of the score. Apparently we manage to get away with this sometimes, but the issue report shows how to get corruption or a crash. My fix detects these cases where we would have run past the end of the selection and accounts for them, hopefully without disturbing anything else.
The second commit addresses the less serious problem in 74946 (the selection after the paste going to the end of the score), which it turns out provides what might be considered a better fix for the original issue. The relevant changes are the ones in Score::pasteStaff(). If mmrests are enabled, I force a relayout before trying to establish the new selection, and I use tick2segmentMM() to establish the start and end segments. This should guarantee the start segment and end segment will not be within "hidden" (beneath mmrests) measures that have not been laid out yet, and would in theory mean my original fix is no longer required.
However, there may be other cases where the selection can get into that state, so better safe than sorry. And while I was at it, I found other corner cases of crashes on pastes involving mmrests in this same place in the code that my original fix did not cover, so I improved that as well with the changes to ScoreView::paint().
So, basically, the first commit addresses the "copy" problem that led to the corruptions and crashes in 74946. The changes to paste.cpp in the second commit addresses the root cause of the "paste" problem that led to the bad selection noted in 74946 as well as the original crash. The changes to scoreview.cpp in that second commit are theoretically not needed with the changes to paste.cpp, but since there might be other ways to get into that situation, they seem good to keep.
Again, I am happy to repackage this as a separate branch, or squash the commits, or separate out the two changes in the second commit.