Crash when entering music on top of an unterminated slur by MIDI
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
won't fix
Regression
No
Workaround
No
Project
This occurs when entering notes with a MIDI keyboard.
Reproduction:
* Create a new score with a grand staff
* Select a bar
* Start entering notes by pressing 'N'
* Enter a note, e.g. press an e on the MIDI keyboard
* Attach a slur by pressing 'S'
* Move back by pressing left arrow
* Select 16th notes by pressing '3'
* Enter the same note on the MIDI keyboard again
Result: Crash
Reproduced with versions 2.2, 2.3.1 and master (nightly build 2018-07-07-0955) on Mac OS X.
Note this only occurs with MIDI note entry. Note entry by computer keyboard is not affected.
Attachment | Size |
---|---|
Bildschirmfoto 2018-07-09 um 21.11.16.png | 27.97 KB |
Comments
Strange … I've just reported this after I was able to reproduce the crash several times in a row. Now I'm trying it again and it no longer crashes.
Anybody else observed this issue?
In reply to Strange … I've just reported… by kontrafuss
OK now, I've updated the description and title. I believe you should now be able to reproduce the issue.
Can you reproduce in a development build?
In reply to Can you reproduce in a… by Jojo-Schmitz
Indeed. Same issue with nightly build (master).
I've added a crash report.
I came here to say that I'm still experiencing this issue and can reliably reproduce it on version 3.6.2 as well as on the latest 3.x development build (commit 415b1927), both on Linux using Jack MIDI. The behavior is very similar to the crash report posted here previously. I dug around a bit inside of the debug build with gdb and it seems the trigger for the error is that in line 258 of noteentry.cpp ("Element* ee = is.slur()->startElement();") ee is assigned a nullpointer, causing a segfault in the following type checks. I also found when startElement is set to 0 and added the backtrace at that particular point (for context: 0x55555d46c770 is the slur object in question). The segfault then occurs in the same function call of addPitch, just a few lines down.
Not knowing the code base I can't really tell what part of that backtrace is not as it should be, but I hope this already helps a bit.
Can also reproduce the #crash on 3.6.2.
Putting an conditional on that ee* resolves the issue.
See https://github.com/musescore/MuseScore/pull/9019
No more fixes for 3.x
It is part of https://github.com/musescore/MuseScore/pull/9000 though, so you could use the artifacts of that