Regression: Crash by entering long notes values immediately after the shortest duration chordrest
GIT commit: d4ea241/ Windows10
1) "My First Score"
2) Enter a 128 th note
3) Enter immediaty after (on the next rest) a whole note
Notes: This issue is encountered with the 128th, 64th and 32nd notes (no issue from what I see for the moment with the 16th) by entering the longest values, such as whole note, double whole note and longa.
There may be a sporadic, or very unstable character. Sometimes, by associating 2 different notes, eg a C and a D, this can avoid, first, a crash. But it's not always verified with a second try (after close et reload "My First Score")
And also, perhaps by associating the selection via the icons of the toolbar and input with the keyboard (or the mouse and the numeric keypad) ?
But apart from a great instability and crashes almost systematic, I do not notice actually a coherence in this inconsistency, except so, the main point of this issue: enter shorter/shortest value + longer/longest value lead to crashes.
I can verify crash on Arch Linux Mate x86-64...made a 128th note C, and then inserted a whole note after.
EDIT: here is stack trace:
1 raise 0x7fffee8dfa10
2 abort 0x7fffee8e113a
3 QMessageLogger::fatal(const char *, ...) const 0x7fffef282e21
4 qt_assert_x(const char *, const char *, const char *, int) 0x7fffef27e441
5 QList::operator qlist.h 548 0xb8d60b
6 Ms::Note::setTrack note.cpp 1996 0x124099a
7 Ms::Chord::add chord.cpp 406 0x1160c0b
8 Ms::Score::setNoteRest cmd.cpp 577 0x136d4fe
9 Ms::Score::putNote edit.cpp 1377 0x11a22fe
10 Ms::Score::addPitch edit.cpp 975 0x11a064b
11 Ms::Score::cmdAddPitch edit.cpp 937 0x11a038f
12 Ms::ScoreView::cmdAddPitch scoreview.cpp 5435 0xa5fc7c
13 Ms::ScoreView::cmd scoreview.cpp 2746 0xa50ac5
14 Ms::MuseScore::cmd musescore.cpp 4671 0xbbcbe6
15 Ms::MuseScore::cmd musescore.cpp 4273 0xbba800
16 Ms::MuseScore::qt_static_metacall moc_musescore_IKSZSQWDH4YDZS.cpp 734 0x1014e67
17 QMetaObject::activate(QObject *, int, int, void * *) 0x7fffef4a2d49
18 Ms::ScoreTab::actionTriggered moc_scoretab_QR4BWIRYNXAVBM.cpp 195 0x101c35b
19 Ms::ScoreTab::qt_static_metacall moc_scoretab_QR4BWIRYNXAVBM.cpp 97 0x101bf66
20 QMetaObject::activate(QObject *, int, int, void * *) 0x7fffef4a2d49
So, after checking, I locate this issue on last March 8
- This nightly works: 8ddd45d
- Crash with this one: 15a2ba4
So, likely a new side effect of this commit ? https://github.com/musescore/MuseScore/pull/3035/files
The immediate next one is: https://github.com/musescore/MuseScore/commit/e871c157099eac839e18d6e74…
According to my stack trace, the dots seem to be problematic:
The assert failure occurs inside the  operator for _dots.
My first hunch would be something to do with the changes to TDuration, like maybe somewhere around here: https://github.com/musescore/MuseScore/commit/7a20001d89dadd9c591b3ddf7…
chord()->dots() evaluates to 4.
But _dots only has 3 elements...and they are all NULL.
Strange. Even though I'm adding a whole note, _durationType equals Ms::TDuration::DurationType::V_HALF (3) which got set in cmd.cpp:574 with chord->setDurationType(d); ...I'm not sure that is right...let me look some more.
crash also if add the whole note after a 128th rest. Just updating title to clarify.
I couldn't look into the details of the bug, but I think it is caused by the "leftover" part of the long note which is inserted in the first measure (or one of the following ones).
The long note is splitted into two or more different measures and a Duration is probably trying to be determined for that fractional length (causing the calculation of a lot of note dots). I guess the problem could be something similar to #28506: Copy / paste corrupts next measure when the pasted note crosses the barline or #35851: Crash when pasting measures in another measure with different actual duration, and I think also #122191: Corruption on delete of 5/8 time signature changing to 3/4.
I think the use of toDurationList or (maybe better) toRhythmicDurationList could be the solution.
Unfortunately, I have virtually no time to work on it at the moment.
That makes sense, because the bug didn't happen when inserting a half note after the 128th rest, but did happen when inserting a whole note or double-whole note after the 128th rest...and that long note must be divided up.
I produced an mtest script:
with similar stack trace:
1 raise 0x7fffefb2ba10
2 abort 0x7fffefb2d13a
3 QMessageLogger::fatal(const char *, ...) const 0x7ffff07e1e21
4 qt_assert_x(const char *, const char *, const char *, int) 0x7ffff07dd441
5 QList::operator qlist.h 548 0x8261c3
6 Ms::Note::setTrack note.cpp 1996 0x89ff2e
7 Ms::Chord::add chord.cpp 406 0x7b2605
8 Ms::Score::setNoteRest cmd.cpp 577 0x9da1f0
9 Ms::Score::putNote edit.cpp 1377 0x7f8922
10 Ms::Score::addPitch edit.cpp 975 0x7f6c6f
11 Ms::Score::cmdAddPitch edit.cpp 937 0x7f69b3
12 TestNote::LongNoteAfterShort_183746 tst_note.cpp 526 0x65a08c
13 TestNote::qt_static_metacall tst_note.moc 74 0x65a1da
14 QMetaMethod::invoke(QObject *, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const 0x7ffff09e18be
15 ?? 0x7ffff726fa57
16 ?? 0x7ffff7270446
17 ?? 0x7ffff7270a82
18 QTest::qExec(QObject *, int, char * *) 0x7ffff7270f91
19 main tst_note.cpp 529 0x65a13d
"y after the shortest duration chordrest [....] Just updating title to clarify."
To clarify? "Duration chordrest" ? For developers, and code specialists surely, but make it completely more obscure for non-specialists! ... "simple" testers and fillers of reports.
Fixed in branch 2.1, commit 9ca7d0b16b
fix #183746: [Regression] Crash by entering long notes values immediately after the shortest duration chordrest
I ran mscore with lasconic's commit, and this is what I get:
So looks good.
I made a test case for the above situation:
https://github.com/musescore/MuseScore/pull/3099 (for 2.1-only)
https://github.com/musescore/MuseScore/pull/3100 (for master-only)
Automatically closed -- issue fixed for 2 weeks with no activity.