Using MIDI input to input chords causes crash

• Aug 22, 2012 - 18:23
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

MuseScore crashes upon the following action:
- Input two or more notes at the same time with my MIDI input device.
The program crashed without fail. It is not a random encounter.

Information:
OS: Windows 7
Build: MuseScoreNightly-2012-08-18
MIDI input device: Roland FP-7
The device works perfectly with the stable 1.2 release.

Comments

• Oct 11, 2012 - 07:03

This bug is still active, note input over midi interface causes crash when you enter more than one note at once.
win7x64 musescore fdd8040

Reply

• Nov 10, 2012 - 03:58

I'm having a similar issue with the same MIDI device (Roland FP-7) on Linux (Ubuntu 12.10 64-bit). Version 1.2 allowed me to use the piano for MINI input, with current trunk I cannot enter any notes using the piano.

If necessary I can do a `git bisect` for this issue.

Reply

• Jan 9, 2013 - 00:18

Any updates on that front? I am finally able to input MIDI, and I'm experiencing the crashes reported here. Below is the gdb backtrace of the crash after holding a C and then entering an E on the piano. The crash occurs as soon as E is pressed (while holding C). Ubuntu 12.10 amd64, latest packages, revision 1778f37b61.

Looks to me like a simple "null pointer" exception.

midiNoteReceived 72 chord 0
add pitch 72 0
expand voice: found Rest 4/4
makeGap 1/4 at 0 track 0
remove Rest 4/4 at tick 0 track 0
  makeGap: remove 4/4 at 0
  makeGap: 1/4 removed 3/4 too much
   dList: 2

   gap at tick 0+480
addClone Rest at 480 1/4
addClone Rest at 960 1/2
midiNoteReceived 76 chord 1
add pitch 76 1

Program received signal SIGSEGV, Segmentation fault.
ScoreView::adjustCanvasPosition (this=0x3201590, el=0x0, playBack=false)
    at /home/muelleki/git/musescore/mscore/scoreview.cpp:3504
3504	      if (el->type() == Element::NOTE)
(gdb) bt
#0  ScoreView::adjustCanvasPosition (this=0x3201590, el=0x0, playBack=false)
    at /home/muelleki/git/musescore/mscore/scoreview.cpp:3504
#1  0x000000000095c9b5 in Score::processMidiInput (this=0x31e35f0) at /home/muelleki/git/musescore/libmscore/cmd.cpp:1584
#2  0x000000000058c22f in ScoreView::cmd (this=this@entry=0x3201590, a=a@entry=0x0)
    at /home/muelleki/git/musescore/mscore/scoreview.cpp:2801
#3  0x000000000058e78a in ScoreView::midiNoteReceived (this=0x3201590, pitch=76, chord=)
    at /home/muelleki/git/musescore/mscore/scoreview.cpp:4713
#4  0x000000000064b888 in MuseScore::midiNoteReceived (this=0x1738ea0, channel=0, pitch=76, velo=)
    at /home/muelleki/git/musescore/mscore/musescore.cpp:1745
#5  0x000000000080c680 in AlsaMidiDriver::read (this=0x19ed1d0) at /home/muelleki/git/musescore/mscore/mididriver.cpp:366
#6  0x00007ffff3c05f5f in QMetaObject::activate (sender=0x1c05030, m=, local_signal_index=, 
    argv=0x7fffffffd170) at kernel/qobject.cpp:3547
#7  0x00007ffff3c5079e in QSocketNotifier::activated (this=, _t1=31)
    at .moc/release-shared/moc_qsocketnotifier.cpp:103
#8  0x00007ffff3c0d7eb in QSocketNotifier::event (this=0x1c05030, e=0x7fffffffd750) at kernel/qsocketnotifier.cpp:317
#9  0x00007ffff4695e9c in QApplicationPrivate::notify_helper (this=this@entry=0x1161b30, receiver=receiver@entry=0x1c05030, 
    e=e@entry=0x7fffffffd750) at kernel/qapplication.cpp:4562
#10 0x00007ffff469a30a in QApplication::notify (this=0x115f910, receiver=0x1c05030, e=0x7fffffffd750)
    at kernel/qapplication.cpp:4423
#11 0x00007ffff3bf056e in QCoreApplication::notifyInternal (this=0x115f910, receiver=0x1c05030, event=0x7fffffffd750)
    at kernel/qcoreapplication.cpp:915
#12 0x00007ffff3c1e3f8 in sendEvent (event=0x7fffffffd750, receiver=)
---Type  to continue, or q  to quit---
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#13 socketNotifierSourceDispatch (source=0x1169af0) at kernel/qeventdispatcher_glib.cpp:110
#14 0x00007fffefaf5ab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007fffefaf5de8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007fffefaf5ea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff3c1ebf6 in QEventDispatcherGlib::processEvents (this=0x1168520, flags=...)
    at kernel/qeventdispatcher_glib.cpp:424
#18 0x00007ffff473ac1e in QGuiEventDispatcherGlib::processEvents (this=, flags=...)
    at kernel/qguieventdispatcher_glib.cpp:204
#19 0x00007ffff3bef2bf in QEventLoop::processEvents (this=this@entry=0x7fffffffd990, flags=...) at kernel/qeventloop.cpp:149
#20 0x00007ffff3bef548 in QEventLoop::exec (this=0x7fffffffd990, flags=...) at kernel/qeventloop.cpp:204
#21 0x00007ffff3bf4708 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1187
#22 0x000000000056595f in main (argc=1, av=) at /home/muelleki/git/musescore/mscore/musescore.cpp:2450

Reply

• Jan 9, 2013 - 15:07

Hi, I've looked into this some days ago.
I think I found a potential fix for the problem, but I did the experiments on a bulk source directory.
I have to properly set up the developer environment before posting the fix here.
I guess I'll have some spare time in the next weekend, so please wait a little bit.
Bye

Reply

• Jan 9, 2013 - 22:55

As far as I understand the problem, the reason is that the check

            if (_is.cr() == 0 || _is.cr()->type() != Element::CHORD)

in libmscore/cmd.cpp:382 (Score::addPitch) fails, which leads to a premature "return 0" in the following line. The returned "0" later causes the trouble. I have checked _is.cr()->type(), it returns Element::REST (value: 17). Just a wild guess: Perhaps moveToNextInputPos() (lines 387 and 447 in the same file/routine) should be called before adding the pitch, and not after?

By the way, are there automated tests for MIDI input in the project?

Reply

• Jan 11, 2013 - 06:50

watery: This is much simpler than my hack, I'd vote for implementing your solution.

My other commit is still valuable: Safeguarding the GUI against further occasions where addNote might return 0. Could you add that to your pull request?

Reply

• Jan 11, 2013 - 10:36

Thank you :)

About your proposal, I'm not sure about it, because I can't tell if by design addNote() is expected to never return 0 - which would make a check on its return value useless, except, of course, in case of a bug; but in the latter case this could hold for almost every other place in the source, so that change should be more, say, structural.

I'll leave a message to lasconic about that.

Reply

• Jan 12, 2013 - 12:44
Status (old) patch (code needs review) ⇒ active

I'm setting this back to active as in my fix sometimes chords aren't properly handled and their notes are inserted separately.

Reply

• Jan 12, 2013 - 13:13

Well, I'm having troubles reproducing my own issue :) what basically happens is that when reiterating:

  • go in "note entry mode";
  • enter some notes and chords;
  • exit "note entry mode";
  • move with the cursor on another note.

After a while the chords are detected but splitted in separate notes.
It seems so random that I'm starting to think it could be due to my digital piano not sending MIDI messages always correctly.
Anyway with my fix I didn't got any more crash, so this could be turned into "normal".

Reply

• Jan 12, 2013 - 13:53

I agree, but I'd like to investigate if the bug is caused by my fix, or is my fix that is making it visible.
Since I can't reproduce the problem, I can't debug it, and I'm no more willing to submit the fix.
Anyway, I wrote everything here so that a more experienced developer can add some suggestions or take the proper decision :)

Reply

• Jan 21, 2013 - 10:23

Now both pull requests got merged, don't they conflict with one another? At least their change to libmscore/cmd.c in the 1st hunk of the patches?

Reply

• Jan 21, 2013 - 10:30

I saw it just now... I can't say anything code-wise (I'll see when I have got some spare time), but from a logical point of view I guess they could, as we both tried to fix the same issue with two different approaches.

Reply

• Jan 21, 2013 - 11:01

And they do :)
in 9e27... build you can enter chords with midi input without a crash but the behavior is just weird.
Entering more than one note with the midi-keyboard adds them randomly elsewhere in the score, not vertically but horizontally.

Reply