"MuseScore quit unexpectedly" when closing MuseScore 3.0.[1-5] on macOS with a MIDI device
Reported version
3.0
Type
Ergonomical (UX)
Frequency
Many
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
When closing the newly released MuseScore 3.0.1 on macOS Mojave the user is confronted with the following dialog:
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 |
Fix version
3.1.0
Comments
Same here on Mac. (macOS High Sierra)
Additionally, "Revert to Factory Settings" cause crash.
Do you happen to have OSC activated?
In reply to Do you happen to have OSC… by rmattes
hello rmattes
you mean,
Preferences-->General-->OSC Remote Control right?
No, I haven't activated this check box.
In reply to Do you happen to have OSC… by rmattes
I don't have OSC activated. MuseScore 3.0.0 worked, 3.0.1 now shows this unwanted behavior.
"MuseScore quit unexpectedly" when closing MuseScore 3.0.1.20439 on MAC Mojave 10.14.2
Also reported in #282762: Musescore 3.0.1 give me a message of "MuseScore quit unexpectedly." every time I quit the program.
Bug still present in MuseScore 3.0.2
"Revert to Factory Settings" causing crash still in 3.0.2
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.
Same thing
In reply to Same thing by synopgtr
I could reproduce a crash one more time. Now everything works as expected. Attached the logfile for that one last crash.
In reply to Same thing by synopgtr
here is...
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.
also reported in https://musescore.org/ja/node/284421#comment-896639
Thank you to all the people who gave feedback (here and in the forum). I think I found the culprit of the crash.
Here is the proposed PR:
https://github.com/musescore/MuseScore/pull/4716
Wow, great work everyone and @ABL in particular 👍
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.
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
Seems a regression alright.
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.
Still present in 3.0.3.
Sure, as the PR hasn't ben merged yet.
Came up again in https://musescore.org/en/node/284878
In reply to Came up again in https:/… by mike320
Today I received an update, version: 3.04, and it doesn't seem to have fixed the problem.
Indeed, the Pr hasn't been merged yet
How is this "S4 - Minor"?
It happens on exit, no harm done.
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.
Came up again today, twice, https://musescore.org/en/3.0.4#comment-901001 and https://musescore.org/en/node/285221#comment-899826
Fixed in branch master, commit 083bb9136e
fix #281867 : Crash when closing MuseScore on Mac with a MIDI device
Fixed in branch master, commit 25ae8bc9f4
_Merge pull request #4716 from AntonioBL/mac_crash_on_exit
fix #281867 : Crash when closing MuseScore on Mac with a MIDI device_
Fixed in branch 3.0.5, commit a15f31a905
_Merge pull request #4716 from AntonioBL/mac_crash_on_exit
fix #281867 : Crash when closing MuseScore on Mac with a MIDI device_
As per #285693: Crash when enabling MIDI via palette button (Version 3.0.4) this still happens in the 3.0.5 prerelease
In reply to (No subject) 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 I also see the crash with… by ABL
In reply to (No subject) 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.
In reply to Cool! Thank you @ABL! In… by chschmid
I unplugged my midi device before launching Musescore 3.0.5 and still got the message "unexpectedly quit" when quitting the app.
same here on mac (Mojave)
MuseScore 3.0.5
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
regards
kolydart.gr
I am getting this error every time I close MuseScore even when I unplug midi devices. Is a fix being developed?
Additional detail:
OS: macOS Mojave (10.14), Arch.: x86_64, MuseScore version (64-bit): 3.0.5.21343, revision: 58dd23d
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): 3.0.5.21343, 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.
In reply to OS: macOS Mojave (10.14),… by [DELETED] 1831606
...hopefully there will be a fix soon
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.
Pete
In reply to The suggestion: Steps to… by petecrosta
@pete steps to reproduce means the steps needed to reproduce the problem, not to fix it.
Also reported at https://musescore.org/en/node/286387
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.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.
-2- modify ptmacosx_cf.c seems least invasive, even if modifying third party code
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.
Running Mac Book Pro 2018, crashes every time for me.
Thank you all for the feedback. I think the safest solution is modifying the Pt_Stop function, even if this involves modifying the PortMidi source. See PR:
https://github.com/musescore/MuseScore/pull/4822
Actually, similar checks are already done under Linux and under Windows.
Error message upon intentionally closing application
Fixed in branch master, commit b141015f81
fix #281867 crash on Mac when stopping porttime
Fixed in branch master, commit d79d294b20
_Merge pull request #4822 from AntonioBL/porttime_mac
fix #281867 crash on Mac when stopping porttime_
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.
Ciao,
ABL
In reply to @BSG : if it is not already… by ABL
I forgot how to make the reference here, but https://musescore.org/en/node/286900 . It turns out there is a UI change problem. See what I wrote and tell me what you think.
#286900: MIDI input menu has no "None" option ([#286900])
Automatically closed -- issue fixed for 2 weeks with no activity.
But after mine crashed, like all my songs title becomes like eg: scdYC586
like all of my created songs renamed it self
That is by design, it is the autosave verrsion of your score.
Better let a 2 years old issue rest in peace...
If you're really still on MuseScore 3.0.x, update to 3.6.2