Crash on adding notes in voice 2 using MIDI or piano keyboard input

• Dec 27, 2018 - 23:53
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

I've discovered Musescore will now crash each time I attempt to add notes in an additional voice to a bar which already has notes in the first voice. I can enter note input mode, select the length of note and the desired voice, then I press a key on my midi keyboard and it sits thinking for a couple of seconds before crashing and closing without error message or warning.

I first discovered this on a score I'd created under the rc (which worked fine for the part of the score I'd already entered), so created a new score within the release version of 3 and discovered the same behaviour. This would appear to be a newly introduced bug as I haven't experienced it before in the various development versions or in v2.

System: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4785, revision: c1a5e4c

Comments

• Dec 28, 2018 - 00:00

Just to confirm, I discovered I still had 3.0 beta installer on my system, so I've installed that and confirmed adding a second voice appears to work fine in it.

System: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4516, revision: 59a11cd

Reply

• Dec 28, 2018 - 00:10

I used the in-app update option to get the "most recent" version (which appears to be the release candidate from the 22nd Dec rather than the release from the 24th?) and can confirm that adding a second voice is absolutely fine here too. So the bug was likely introduced between the rc and release.

System: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4747, revision: 96c1f7b

Reply

• Dec 28, 2018 - 01:20
Title Muscore crashes on adding a second voice to a bar containing notes in the first voice ⇒ Crash on adding notes in voice 2 using MIDI or piano keyboard input
Priority ⇒ P0 - Critical

I can confirm with the Piano Keyboard. Steps to reproduce:

1) default empty score
2) measure 1, note input mode
3) press "P" for piano keyboard
4) switch to voice 2
5) press a key

Result: crash in processMidiInput(), null dereference on cr

Reply

• Dec 28, 2018 - 07:05

As Marc pointed out, there is a null dereference on cr. The line above the cr->isChord() that causes the null dereference is:

Element* cr = _is.lastSegment()->element(_is.track());

seems to correctly return null.

Reply

• Dec 28, 2018 - 10:09
Status PR created ⇒ fixed

Fixed in branch master, commit e2950adf4c

fix #280771 midi entry on empty voice

Previous code would crash because cr would (correctly) be set to NULL when there are no elements in a particular track of input state's last segment. Once case this situtation occurs is when inputting midi for with a voice that hasn't been used before. This commit prevents this crash by making sure cr is non-NULL before testing if it is a chord.

Reply

Fix version
3.0.1