Crash when opening score (memory fault core dumped)

The score stems from MuseScore 2.0.3. And MuseScore 3.5.2 does not crash on it -> Regression
(3.6.2 on Windows 10 does crash too)

Stack trace:
1 Ms::ScoreElement::score scoreElement.h 189 0x104e35c
2 Ms::Element::concertPitch element.cpp 1676 0x9a053a
3 Ms::Note::concertPitchIdx note.cpp 681 0x1054418
4 Ms::Note::tpc note.cpp 806 0xa34617
5 Ms::Chord::cmdUpdateNotes chord.cpp 1775 0x942359
6 Ms::Score::getNextMeasure layout.cpp 3085 0x9f6d10
7 Ms::Score::collectSystem layout.cpp 4031 0x9fc6f4
8 Ms::LayoutContext::collectPage layout.cpp 4842 0xa02081
9 Ms::LayoutContext::layout layout.cpp 5160 0xa03d0c
10 Ms::Score::doLayoutRange layout.cpp 5148 0xa03c6c
11 Ms::Score::update cmd.cpp 302 0x535f78
12 Ms::Score::update score.h 756 0xf2926a
13 Ms::readScore file.cpp 2437 0x4cc821
14 Ms::MuseScore::readScore file.cpp 474 0x4bcb6c
15 Ms::MuseScore::openScore file.cpp 416 0x4bc62c
16 Ms::MuseScore::doLoadFiles file.cpp 349 0x4bbd73
17 Ms::MuseScore::openFiles file.cpp 314 0x4bb9bc
18 Ms::MuseScore::cmd musescore.cpp 6239 0x4317b3
19 Ms::MuseScore::cmd musescore.cpp 6031 0x4306e2
20 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 540 0x5ee715
...

As I recall, early 2.0 releases had a pretty bad TPC corruption issue that we fixed at some point soon and we attempted to correct broken scores on read but it wasn't always possible. Based on the stack trace, chances are that's related, and other versions of MuseScore might have had other issues with the relevant notes, displaying incorrect octaves or transpositions. Not sure what might have changed to make 3.6 crash if 3.5 didn't, though.

Workaround' open with 3.5.2 or 2.3.2 (e.g. AppImage or PortableApp) and save.
After that it opens in 3.6.2 without a crash too

@Marc Sabatella are you maybe talking about #81091: tpc corruption adding notes after transposing Instrument change and #9352: Add ability to set transposition by range, fixed in 2.1?

If running without debugger (and only if) I get this fatal assert (perhaps unrelated):
Fatal: ASSERT: "!startElement() || startElement()->type() == ElementType::NOTE" in file C:\cygwin64\home\larry\ms\msj\libmscore\tie.cpp, line 801 (C:\cygwin64\home\larry\ms\msj\libmscore\tie.cpp:801, )

Confirmed, same assert outside debugger. Strange...

Hmm, OK, in debuggger too, somethimes?

Stacktrace then (breakpoint at the assert):

1 Ms::Tie::startNote tie.cpp 873 0xaa6946
2 Ms::Note::connectTiedNotes note.cpp 3498 0xa418b5
3 Ms::Chord::add chord.cpp 549 0x93cffa
4 Ms::readChord read206.cpp 2108 0xbb912b
5 Ms::readMeasure read206.cpp 2703 0xbbbdb8
6 Ms::readStaffContent read206.cpp 3300 0xbbf89e
7 Ms::readScore read206.cpp 3487 0xbc0e51
8 Ms::MasterScore::read206 read206.cpp 3821 0xbc30e9
9 Ms::MasterScore::read1 scorefile.cpp 1041 0xb4a772
10 Ms::MasterScore::loadCompressedMsc scorefile.cpp 859 0xb4969e
11 Ms::MasterScore::loadMsc scorefile.cpp 946 0xb49d58
12 Ms::MasterScore::loadMsc scorefile.cpp 937 0xb49bbd
13 Ms::::operator()(Ms::MasterScore *, const QString &, bool, bool) const file.cpp 2328 0x4cbe65
14 Ms::readScore file.cpp 2336 0x4cc115
15 Ms::MuseScore::readScore file.cpp 474 0x4bcb6c
16 Ms::MuseScore::openScore file.cpp 416 0x4bc62c
17 Ms::MuseScore::dropEvent musescore.cpp 2933 0x41b7ea
18 QWidget::event(QEvent *) 0x32883d78
19 QMainWindow::event(QEvent *) 0x3297bff3
20 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x3284790e
...

It is a tied to 8th G5 single note chord, probably in the top staff and somewhere between measure 66 and 119

Debug: next note at 165360 track 0 for tie not found (version 206) (...\libmscore\layout.cpp:1464, void Ms::Score::connectTies(bool))
...
Debug: ---link 1802 not found (5120) (...\libmscore\element.cpp:743, virtual bool Ms::Element::readProperties(Ms::XmlReader&))
...
Debug: zero slur at tick 117600(118320) track 0 in measure 61-61 tick 118320 ticks 0 (...\libmscore\slur.cpp:254, virtual void Ms::SlurSegment::computeBezier(QPointF))
...
Debug: zero slur at tick 228960(228960) track 0 in measure 119-119 tick 228960 ticks 0 (...\libmscore\slur.cpp:254, virtual void Ms::SlurSegment::computeBezier(QPointF))

Nonsense, the crash is on some tied note at or after measure 119, or at a non-first staff, as that's the 'famous last words', the "tied to 8th G5 single note chord" was just the 1st hit of the breakpoint

And it got to be related to parts, as when opening the score in 2.0.3, removing all parts and saving, it then opens with crash in 3.6.2.
Also when deleting and regenerating all parts in 2.0.3

And it got to the the 2nd part, Flute-1, as removing (and regenerating) that (in 2.0.3) alone already fixes the crash

Crash has occurred for days, whenever I try to save any file, even sham file with only one measure. I no longer have the files I made to attach, as I am a new user. I deleted the files and uninstalled-reinstalled the app several times, thinking that would help. Also have done system troubleshooting and updates. New reinstall today, tried to save then crashes.

I tried opening that file on this thread, also crashes.

May or may not be the same issue, attach your score and we'll see.
Also reinstall only rarely fixes issues, reverting to factory settings does much more often

That seems like what I'm remembering indeed. In particular, the fix was this code:

https://github.com/musescore/MuseScore/pull/2228/files#diff-9e1893cbcd2…

added as part of more general improvements in ability to handle instrument changes that involve different transpositions. Note also the comment referencing https://musescore.org/en/node/74746. The handling of tpc's was changed for MuseScore 2 as I recall, and I am "pretty sure" there were other bugs too, some fixed during beta, some not until after release.

So anyhow, I don't know for sure that's related to what's going on here, but it seems plausible based on what we know.

Unlikely related to that or #74746: Diatonic transpositions incorrectly handled for transposed instruments [reproducible], as there are no transposing instruments involved.
And I didn't get it to crash with that stack trace anymore, maybe back then something else was going on

Well, as I said, there were other ways to get TPC corruption, that particular bug just happened to be the one I optimized for in my fix. So I wouldn't rule it out yet. but if that's not where it crashes now, probably it's a red herring indeed.