Using MIDI input to input chords causes crash

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

kirillmueller

• 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

watery

• 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

kirillmueller

• 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

kirillmueller

• Jan 10, 2013 - 07:42

Added pull request for bugfix: https://github.com/musescore/MuseScore/pull/166

Reply

watery

• Jan 11, 2013 - 01:18

I took a different path to fix this: https://github.com/musescore/MuseScore/pull/167 - it works here, however this is the first time I look into the sources, so comments are really welcome :)

Reply

kirillmueller

• 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

watery

• 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

watery

• Jan 12, 2013 - 12:08

Status (old)

active

⇒

patch (code needs review)

Reply

watery

• 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

watery

• 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

chen lung

• Jan 12, 2013 - 13:24

If a bug isn't reproducible, it would be better to close the issue for it and file a separate one for others :).

Reply

watery

• 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

chen lung

• Jan 12, 2013 - 15:35

You can leave it open if you want - someone else might be able to reproduce?

Reply

System Message

• Jan 21, 2013 - 08:56

Status (old)

active

⇒

fixed

Fixed in 9e27b5ad4b

Reply

Jojo-Schmitz

• 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

watery

• 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

zephyrus

• 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

Jojo-Schmitz

• Jan 21, 2013 - 11:39

Status (old)

fixed

⇒

active

Reply

watery

• Jan 21, 2013 - 21:46

Thank you zephyrus for your test.
I left a comment on my pull request.

Reply