Sample score and exact steps to reproduce please

Copy what exactly? Paste where exactly?

It's normal, BTW, that "undo" state is not remembered between sessions - not just for MuseScore, but for pretty much any program.

For the record, though, a crash cannot ever lose data you have actually saved. Yes, the "autosave" will only recover up to the last two minutes so any unsaved work done within the last couple of minutes is lost. But always if you save a file, that file stays saved - there is nothing can ever go back and remove music from an already-saved score.

Reproducible from scratch, see :

May or may not be the issue the OP has, but so far that score doesn't have multimeasure rests. They are enabled for that score though, just no empty measures there.

See my post above, it explains that the only data lost is that which you haven't saved, perfectly normal.

Certainly of interest, but a different issue.

stack trace for this crash here:

1 std::vector::size stl_vector.h 806 0x10a832c
2 Ms::Segment::element segment.cpp 426 0xa7e91d
3 Ms::findLinkedChord edit.cpp 4163 0x984f1a
4 Ms::Score::undoAddElement edit.cpp 4916 0x9894ba
5 Ms::Score::setNoteRest cmd.cpp 793 0x53750c
6 Ms::ChordRest::drop chordrest.cpp 516 0x95cbe4
7 Ms::Rest::drop rest.cpp 288 0xa5ff13
8 Ms::Score::cmdPaste paste.cpp 1027 0xb6d2ac
9 Ms::ScoreView::normalPaste scoreview.cpp 2046 0x640005
10 Ms::ScoreView::::operator()(Ms::ScoreView *, const QByteArray &) const scoreview.cpp 2132 0x64043a
11 std::_Function_handler>::_M_invoke(const std::_Any_data &, Ms::ScoreView *&&, const QByteArray &) std_function.h 297 0x65b48b
12 std::function::operator()(Ms::ScoreView *, QByteArray const&) const std_function.h 687 0x10b6dcd
13 Ms::ScoreView::cmd scoreview.cpp 2890 0x648b79
14 Ms::ScoreView::cmd scoreview.cpp 2089 0x64025f
15 Ms::MuseScore::cmd musescore.cpp 6609 0x433d70
16 Ms::MuseScore::cmd musescore.cpp 6040 0x430706
17 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 524 0x5ecadc
18 void doActivate(QObject *, int, void * *) 0x68b978bb
19 Ms::ScoreTab::actionTriggered moc_scoretab.cpp 226 0x60bc0a
20 Ms::ScoreTab::qt_static_metacall moc_scoretab.cpp 111 0x60b679
...

Happens in 3.5 too (and probably older versions too)

Workaround is to disable multimeasure rests before pasting, or not to paste onto multimeasure rests in the first place.

See https://github.com/musescore/MuseScore/pull/8816

Copying (just) a tie onto a (normal) rest still causes a crash, even with that PR. Might be a different issue altogether though

Could you describe how you produce that crash? With the attached score, copying the tie, select the half-note rest and then paste, doesn't do anything.

.

Hmm, not without your PR, not in 3.6.2, but with it in 3.x (plus quite a few more, so might be caused by one of those)

I take that back, doesn't happen with the Artifact from your PR, must be one of the other changes in my branch (or the fact that it es a QtCreator/MinGW Debug build), oh boy, looks like a lenghty git bisect is due :-(

Yes, I can reproduce it with your branch (3.x + goodies) at commit a6b238f, and only for ties, slur will not crash (and nothing is copied).
Here is the stack:

0 0x00007ff6d1ab790c in Ms::Element::parent (this=0x0) at libmscore/element.h:199

1 0x00007ff6d1ab28d8 in Ms::Note::chord (this=0x0) at libmscore/note.h:429

2 0x00007ff6d13f9bd9 in Ms::Score::undoAddElement (this=0x2a5e9c3ed50, element=0x2a5e9a3e570) at libmscore\edit.cpp:4914

3 0x00007ff6d13ce333 in Ms::ChordRest::drop (this=0x2a5f7e7b4d0, data=...) at libmscore\chordrest.cpp:635

4 0x00007ff6d14cfe1a in Ms::Rest::drop (this=0x2a5f7e7b4d0, data=...) at libmscore\rest.cpp:287

5 0x00007ff6d15dbb41 in Ms::Score::cmdPaste (this=0x2a5e9c3ed50, ms=0x2a5e0178680, view=0x2a5e988e330, scale=...) at libmscore\paste.cpp:1036

6 0x00007ff6d109c53e in Ms::ScoreView::normalPaste (this=0x2a5e988e300, scale=...) at mscore\scoreview.cpp:2046

7 0x00007ff6d109c976 in operator() (__closure=0x2a5f53bcd18, cv=0x2a5e988e300) at mscore\scoreview.cpp:2132

8 0x00007ff6d10cac9d in std::__invoke_impl&, Ms::ScoreView*, const QByteArray&>(std::__invoke_other, struct {...} &) (__f=...) at mingw64/include/c++/10.3.0/bits/invoke.h:60

9 0x00007ff6d10bfbc5 in std::__invoke_r&, Ms::ScoreView*, const QByteArray&>(struct {...} &) (__fn=...) at mingw64/include/c++/10.3.0/bits/invoke.h:153

10 0x00007ff6d10b6e2d in std::_Function_handler >::_M_invoke(const std::_Any_data &, Ms::ScoreView *&&, const QByteArray &) (__functor=..., __args#0=@0xb06a3f8d08: 0x2a5e988e300, __args#1=...) at mingw64/include/c++/10.3.0/bits/std_function.h:291

11 0x00007ff6d1b235ff in std::function::operator()(Ms::ScoreView*, QByteArray const&) const (this=0x2a5f53bcd18, __args#0=0x2a5e988e300, __args#1=...) at mingw64/include/c++/10.3.0/bits/std_function.h:622

12 0x00007ff6d10a513a in Ms::ScoreView::cmd (this=0x2a5e988e300, s=0x2a5de4e8008 "paste") at mscore\scoreview.cpp:2890

You can't by chance specify closer which commit might have caused it, can you?
That branch does not (yet) have your PR merged though, let me push it.

This seems fix it:

diff --git a/libmscore/rest.cpp b/libmscore/rest.cpp
index 31adff8cf..780d55347 100644
--- a/libmscore/rest.cpp
+++ b/libmscore/rest.cpp
@@ -286,6 +286,10 @@ Element* Rest::drop(EditData& data)
                   score()->undoAddElement(e);
                   return e;
 
+            case ElementType::TIE:
+                  delete e;
+                  break;
+
             default:
                   return ChordRest::drop(data);
             }
 
<(cpp>

As does:

diff --git a/libmscore/rest.cpp b/libmscore/rest.cpp
index 31adff8cf..78c2c65f3 100644
--- a/libmscore/rest.cpp
+++ b/libmscore/rest.cpp
@@ -232,7 +232,7 @@ bool Rest::acceptDrop(EditData& data) const
          ) {
             return true;
             }
-      return type != ElementType::SLUR && e->isSpanner();
+      return type != ElementType::SLUR && type != ElementType::TIE && e->isSpanner();
       }
 
 //---------------------------------------------------------

Which gives the very strong indication that (my backport of) PR #8510 caused this.

I was trying to test this and multi-measure rests are very weird in MuseScore - can you really only have them on or off for the whole score? (other than using the "break MM rest" option for measures, which is something you can't even visibly detect, if MM rests are off)
I just expected you could select a range of empty measures and choose to either show them as multi-measure rests or not...(it'd be nice if you could actually have them on for one staff even if other staffs don't have empty measures, but I accept that's fairly non-standard and having multi-measure rests that span systems would look pretty odd - though you could always just have one per system).
At any rate the 'toggle multimeasure rests' command isn't available in current builds of v4.0, making it hard to determine if it's still a problem!)

MM rests are indeed a score wide style setting

Which I agree would make sense for 95% of use cases... but considering some of the particularly obscure stuff MuseScore does support, it still surprises me - Encore used to allow easily turning them on and off per measure, and actually having a single measure shown with the same format is not that uncommon either (e.g. if there's a long tacet passage in one time signature with a single measure in a different time signature in the middle).

Maybe one day we can get away from it being (only) a score wide setting.
Feel free to submitt a corresponding Suggestion or even better implement it ;-)

Well importantly there are still issues pasting on to MM rests in v4 (the toggle command is just a quick way to change it via the Style settings), but I'm fixing it so it works as expected (basically the same as entering a note when an MM rest is selected, i.e. the measure is no longer included in the MM rest and the note is added as though it were a regular whole measure rest).

PR for master: https://github.com/musescore/MuseScore/pull/8818
Or even https://github.com/musescore/MuseScore/pull/8825

PR got closed, no further fixes for 3.x