"MuseScore quit unexpectedly" when closing MuseScore 3.0.[1-5] on macOS with a MIDI device

• Jan 15, 2019 - 17:58
Reported version
Ergonomical (UX)
S4 - Minor

When closing the newly released MuseScore 3.0.1 on macOS Mojave the user is confronted with the following dialog:

Screenshot 2019-01-15 at 18.50.57.png

Steps to reproduce:
1) Open MuseScore
2) Close "Start Center" Dialog
3) MuseScore -> Quit MuseScore (or Command - Q)

This dialog should not appear.

Attached also the crash report (report.txt)

Attachment Size
report.txt 105.9 KB


Title "MuseScore quit unexpectedly" when closing MuseScore 3.0.1 on macOS "MuseScore quit unexpectedly" when closing MuseScore 3.0.[12] on macOS

I can't reproduce the bug, it is probably specific to some interactions with other installed softwares.
In order to try to investigate, I managed to build a debug version of one of yesterday nightly build enabling also AddressSanitizer.
If someone experiencing the bug wants to help us in pinpointing the problem, here are the instructions:
- download the dmg here https://drive.google.com/open?id=1lPJVr-RBx6sW7r5ibYMobzcrXKpjQV9d and install MusescoreNightly-Debug in the Applications folder (as for a usual nightly build)
- open the terminal
- type the following commands:
cd ~/Desktop
/Applications/MuseScoreNightly-Debug.app/Contents/MacOS/mscore -d &>mscorelog.txt

- the application should launch in debug mode (it will be definitely slower than a usual MuseScore Nightly)
- reproduce the bug
- a txt file "mscorelog.txt" should have been created in the Desktop, please attach it to a comment in this thread.
Hopefully the log will contain the line number and stack trace for this bug, as well as some additional information of the state of MuseScore at the time of the bug, so we can try to fix it.
Thank you very much for your help.

Sorry that I couldn't answer before: thank you very much for the log file.
Unfortunately, it is not as revealing as I hoped. Maybe more information can be obtained if, before launching the debug mscore, the following environmental variable is defined:
export ASAN_OPTIONS=halt_on_error=0
so that the debug build tries to continue even if some memory errors are found.

I am still investigating this bug.
I found one bug using AddressSanitizer under Linux where it seems that at exit we are trying to delete a unique_ptr which aready atomatically got deleted, but I am not sure at all that that is this current bug.

Musescore 3.0.2 stopped suddenly in my MacBook Air. However, I had time enough to look at a few functions after downloading the latest version. Without knowing the purpose of the developers it is difficult to judge but this seems to be developing to wrong direction. E.g the chord symbol format is note restored when opening a previous score and the style format window is not available anymore with right click. And there are previously reported bugs...

Style format window not being available via right-click anymore is by design, that functionality has moved to the inspector.
Chord symbol style not being restored could be a bug, we'd need a score to reproduce
Your MuseScore having stopped has got nothing to do with the issue at hand here, which is that MuseScore crashes on exit on Mac, if it has a MIDI keyborad attached.

Cool! Thank you @ABL! In line with your root cause analysis: I just realized that in MuseScore 3.0.2 the crash does not happen, when I unplug all MIDI devices before launching MuseScore.

Regression Yes No

Unfortunately, I consistenly get the crash when closing MuseScore 3.0.2, whether or not I have any MIDI devices or other devices connected to my system. I'm running it on macOS High Sierra 10.13.6 (17G5019) on a MacBook Pro (15-inch, 2017).

I thought perhaps the issue was with my MIDI Settings in the Preference I/O tab, and made the following observations:
- I cannot deselect PortAudio, to deactivate MIDI Input
- for MIDI input, I can only pick one of three values: CoreMIDI,IAC Bus 1, CoreMIDI,IAC Bus 2 or CoreMIDI,Network Session 1
- for MIDI output, the initial value is blank; I can choose between blank and the same three values as for MIDI Input

Further, I was trying to see if using Toggle MIDI input on the UI made a difference, and observed:
- it is on by default
- if I turn it off and close the app, the app consistently crashes, and upon restarting the value is reset to on
- if I toggle the value off, and then toggle it back to on, the app immediately crashes

I wasn't sure if would be considered a regression since the issue was originally reported in 3.0.1 and I'm just confirming that I still see it in 3.0.2.
In any case, fwiw I just downloaded and confirmed the same behaviour on the most recent nightly build, MuseScoreNightly-2019-02-23-1156-master-383b6d9.dmg.

Title "MuseScore quit unexpectedly" when closing MuseScore 3.0.[12] on macOS "MuseScore quit unexpectedly" when closing MuseScore 3.0.[123] on macOS

Still present in 3.0.3.

Title "MuseScore quit unexpectedly" when closing MuseScore 3.0.[123] on macOS "MuseScore quit unexpectedly" when closing MuseScore 3.0.[1-4] on macOS

Indeed, the Pr hasn't been merged yet

Hi there. This bug seems to cause MuseScore not to save shortcut preferences, meaning I have to reassign the shortcuts each time I start MuseScore.

I also noticed the problem goes away if I switch from PortAudio to JACK Audio Server in the I/O tab. Well, first MuseScore crashes when doing the change (since the midi driver is closed which seems to trigger the crash), but after restarting MuseScore again I can then quit without getting the crash.

Title "MuseScore quit unexpectedly" when closing MuseScore 3.0.[1-4] on macOS "MuseScore quit unexpectedly" when closing MuseScore 3.0.[1-4] on macOS with a MIDI device

In reply to by Jojo-Schmitz

I also see the crash with the pre-release of 3.0.5, but I cannot reproduce with a local build. I tried with debug, debug+addressSanitizer, release build, but none of them showed the crash, only the automatic build one.
By closely looking at the crash report, I think that the bug I patched was indeed a slightly different one; this bug seems to be a tentative by the program to double release a pointer, but without being able to reproduce under addressSanitizer (or any local debug or release build) it is difficult to pinpoint when the first delete happens.
I think I will try to see if I can reproduce the bug with a Travis build of my GitHub account and, in that case, if I can enable a debug Travis build.

In reply to by chschmid

I found that the crash happens when calling porttime Pt_Stop() function when deleting the mididriver.
In the build from Travis it calls Pt_Stop() from ptmacosx_cf.c and this is causing the crash (error: address points to the zero page; so it is not a double delete action). In my local build it is using Pt_Stop() from ptmacosx_mach.c, and this is not causing the crash, but it also gives portmidi error 'Invalid device ID'.
I tried to cancel ptmacosx_cf.c here https://github.com/musescore/MuseScore/blob/9e69e334b3126853b56c8dfdc11… so that it is not compiled into MuseScore and I have no more crash in the resulting application, but it also shows the portmidi 'Invalid device ID' error. However I have only a virtual midi device, not a real one, so I don't know if it could be a real problem in loading an actual midi device.

I was able to fix it on my MacOS 10.12.
I had a MIDI Driver (IAC Driver) enabled (online). The solution in my situation was the following:
- I opened /Applications/Utilities/Audio MIDI Setup.app
- Double clicked on "IAC Driver" (made sure the "Test Midi setup mode" button was disabled)
- Unchecked "Device is online"
- Quit the Audio MIDI Setup.app
- Opened Musescore & quit without crashing

I hope this helps a bit

I'm running Mac OS 10.13.6 High Sierra and just upgraded to Musescore 3.0.5. Still having an issue with getting the unexpected quit when closing the app. Tried the Midi device procedure without success.

OS: macOS Mojave (10.14), Arch.: x86_64, MuseScore version (64-bit):, revision: 58dd23d

Turning off "Device is online" in the Audio MIDI Setup did not prevent a crash on Quit for me.

Turning on "JACK Audio server" crashed instantly and causes chaos when app restarted.

This is as repeatable as the setting of the sun. If there is any doubt, create an "IAC Bus" in the Audio MIDI Setup applet, and MuseScore will handle the rest, as it were ...

The suggestion:

Steps to reproduce:
1) Open MuseScore
2) Close "Start Center" Dialog
3) MuseScore -> Quit MuseScore (or Command - Q)

DOES NOT WORK! I have tried it numerous times since placing v3 on my Mac Mojave. This is a most annoying concern.


Attachment Size
CRASH-v305.txt 87.2 KB

I think I found the cause of the crash, but I don't know how to deal with it.
From what I see, when the midi driver is initialized, a timer "is" started, here: https://github.com/musescore/MuseScore/blob/f69ad3335ddd1c9df3c3e287768…
but actually no real timer is created since the callback function (second argument of Pt_Start function) is zero.
See here: https://github.com/musescore/MuseScore/blob/38f74fe07082e85d65cf85406a8…
In particular, callback is 0 and thus no timer thread is created.
Therefore, when calling the Pt_Stop function here: https://github.com/musescore/MuseScore/blob/f69ad3335ddd1c9df3c3e287768…
it tries to stop the runLoop of the timer, here: https://github.com/musescore/MuseScore/blob/38f74fe07082e85d65cf85406a8…
but the timer is 0 and this causes the crash.

Now, here are the possibilities I see for dealing with this bug:
-1- do not call Pt_Start nor Pt_Stop; I sincerely do not understand what that Pt_Start is doing since no timer thread is created; if I understand the code correctly no timer is created even under Linux ( https://github.com/musescore/MuseScore/blob/38f74fe07082e85d65cf85406a8… ) or Windows ( https://github.com/musescore/MuseScore/blob/38f74fe07082e85d65cf85406a8… );
-2- modify ptmacosx_cf.c here https://github.com/musescore/MuseScore/blob/38f74fe07082e85d65cf85406a8… so that CFRunLoopStop is called only if timerRunLoop is not 0.

  • Other ideas? (since I actually have no experience in midi input/output)

I am not an expert on this code, but a summary lookover suggests that Pt_Stop is called all over the place, so whoever coded this clearly expects a timer (of currently mysterious function) to be running, and has taken care to put strew now-problematic calls to stop it around. It would seem that the best idea would be to handle the "no real timer case", perhaps by a conditional before each such call, acknowledging the current state until either the motivation of the timer is figured out, or the whole timer mechanism excised.

Still crashing with every version of Musescore 3 on my iMac when closing the app. MacBook Pro seems to be fine - as a quick test installation suggested.

Any hope of fixing the lack of a "None, please" option in the MIDI input slot this round, too? [b]I hate documenting bugs in tutorials![/b].

@BSG : if it is not already present in the issue tracker, could you please open a new issue report for such a problem, possibly with the steps for reproducing?
(When dealing with the bug of this report, I observed that sometimes, after disabling and re-enabling the MIDI interface, MuseScore cannot recognize the MIDI device, but I couldn't reproduce in a systematic manner, and I don't know if it is the issue you are referencing in the comment)
Thank you.

Fix version