MuseScore crashes when attempting to open or save files
I'm running MuseScore on Fedora 22 (64-bit). MuseScore consistently crashes when I try to open or save files. I've tried the version in the Fedora repos (2.0.0) and tried compiling the latest release (2.0.2) but it's made no difference. Here's what happens.
First I start MuseScore from the applications menu like normal. I see Start Center. There's also a small dialog that says "Loading", but its progress bar never fills up, and it never closes. I can't open any files. Clicking from the Start Center, the folder button on the main GUI, and using the menu File > Open all cause MuseScore to crash. I have to open the files from the commandline. From there, everything I've tried so far seems okay -- I can enter notes and change formatting settings -- but it crashes again when I try to save.
So I try running MuseScore from the terminal in debugging mode (mscore -d /path/to/my/project.mscz. I go the page Layout menu, change the page size, switch to landscape layout, and fiddle with the margins. Then I try to save, and MuseScore crashes. Here's the output:
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)
I've also tried starting a new project based on the default template, entering some notes, and then click to "Save As". There's one extra line in the terminal output when it crashes, but otherwise it's the same:
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
QNetworkReplyImplPrivate::error: Internal problem, this method must only be called once.
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)
The only difference when I repeated these steps after compiling MuseScore 2.0.2 is that the terminal output doesn't have the libpng warnings anymore. Otherwise, it's the same results.
Any ideas how I can get this working again?
Comments
"Loading" dialog is an indication that you or your package manager compiled MuseScore with Qt 5.5. That could be the problem.
In reply to "Loading" dialog is an by [DELETED] 5
I got a friend who is also running Fedora 22 to install MuseScore from the repositories, and everything works fine for her. So I don't think it's a problem with how the Fedora maintainers compiled and packaged MuseScore.
I do have Qt 5.5 on my system, though. I don't have any control over the Fedora repos, and the instructions on how to compile MuseScore don't talk about how to configure, well, anything about the compilation process. So what do I do?
In reply to I got a friend who is also by andrewtoskin
...Actually, I'm not entirely sure which Qt package I should be looking at -- mscore depends on several "qt" packages. The plain
qtpackage is version 4.8.6.qt5-qtbase,qt5-qtquickcontrols, andqt5-qtdeclarativeare at version 5.5.0...qtscriptbindingsis 0.2.0.Have you tried resetting MuseScore to factory default settings?
It probably won't solve these particular problems, but it's always worth trying. I've found it necessary every time I have upgraded MuseScore.
In reply to Have you tried resetting by shoogle
This was a fresh installation, so running
mscore -Fdidn't make any difference. But thanks anyway, though, I'll remember to try that again in case of future issues.That libpng warning sems to hint at an outdated Qt library, should have been fixed in newer ones. Wonder whether the crash due to bad allo is fixed there too. It seems likely, see #46031: segmentation fault when trying to print
In reply to That libpng warning sems to by Jojo-Schmitz
Haha, are my Qt libraries too new or too old?
I compiled MuseScore 2.0.2, which was released a month after that thread was marked as resolved, so any of those issues related to the core application should be fixed, right? So which version of which Qt libraries do I need?
In reply to Haha, are my Qt libraries too by andrewtoskin
Qt 5.4.2 is what is used for Mac and Windows and also for the Linux builds on Travis
In reply to Qt 5.4.2 is what is used for by Jojo-Schmitz
Okay, so I downgraded the Qt libraries as best as I could figure.
> sudo dnf downgrade qt5-qttools qt5-qtbase qt5-qtquickcontrols qt5-qtdeclarative --allowerasingWhich removed
qt5-designer,qt5-linguist,qt5-qhelpgenerator...and downgraded all of the following packages from version 5.5.0 to 5.4.1 (I'd really like to not have to also compile Qt to make sure to get exactly 5.4.2 -- is this close enough?):
python-qt5,qt5-qtbase,qt5-qtbase,qt5-qtbase,qt5-qtbase,qt5-qtconnectivity,qt5-qtdeclarative,qt5-qtdeclarative,qt5-qtlocation,qt5-qtmultimedia,qt5-qtquick1,qt5-qtquick1,qt5-qtquickcontrols,qt5-qtscript,qt5-qtscript,qt5-qtsensors,qt5-qtserialport,qt5-qtsvg,qt5-qtsvg,qt5-qttools,qt5-qttools,qt5-qttools,qt5-qttools,qt5-qttools,qt5-qttools,qt5-qttools,qt5-qttools,qt5-qtwebchannel,qt5-qtwebkit,qt5-qtwebkit,qt5-qtwebsockets,qt5-qtx11extras,qt5-qtxmlpatterns,qt5-qtxmlpatternsI think that covers all the MuseScore dependencies, but let me know if I missed one.
I then reinstalled MuseScore from the Fedora repositories (v2.0.0) and it still crashes with the same error messages, including the libpng warnings. I notice the "Loading" dialog is gone, though, so hurray for progress! :(
I also recompiled MuseScore 2.0.2. It still crashes, but with slightly different error messages this time. There's no sound playback, and the FluidSynth error repeated for each note I entered into the template document:
Otherwise, no changes. MuseScore still crasahes when I try to open or save files.
I'm bumping this thread. Does anyone have any more ideas of how I can fix this?
I'd really like to get back to work with MuseScore, but I still can't save my progress.
In reply to I'm bumping this thread. Does by andrewtoskin
You could try to start MuseScore with the
-soption (mscore -s) to see if the problem is in the synthesizer (since there are those FluidSynth errors). Of course, in this case you will have no sound.I doubt that this will solve the crash, since you are saying that it is related to saving or opening files.
It would be interesting if you could provide a backtrace, maybe running MuseScore inside gdb.
gdb mscorerun -d
(reproduce the crash)
bt
With addressSanitizer I see a font-related problem when saving files, but this does not lead to a crash when normally using mscore without addressSanitizer.
Ciao,
ABL
In reply to You could try to start by ABL
Thanks, ABL
Running MuseScore with the
-sswitch doesn't change much. It got rid of the FluidSynth errors when entering random notes in the compiled version, but both the compiled and repository versions of MuseScore still crash when attempting to open or save a file.Hopefully the debug output will make sense to you, because this is just a bunch of noise to me...
EDIT: Looking a little closer, I noticed that when I first ran gdb, a lot of the output had to do with missing debug symbols, so I needed to install a bunch of debug files and run gdb again. Hopefully I did this correctly.
Debugging the Fedora repo version (mscore 2.0.0)
First, install debug symbols:
sudo dnf debuginfo-install mscore(gdb still lists a couple missing debug files, though, even after I explicitly installed them...)
Then, I run MuseScore in gdb. I cancel attempts to restart the previous session, close the Start Center, and then try to open a file by clicking on the folder icon:
> gdb mscore...I notice the lines about CRC Mismatch mention things like "/usr/lib/debug//usr/lib64/libc-2.21.so.debug". Is that a problem in the MuseScore debug files? There shouldn't be a double slash in the path, right?
Debugging the compiled version (mscore 2.0.2)
During my first attempt at debugging the compiled version, gdb listed a whole bunch more missing debug symbols. Some of these I'm not entirely sure if they actually matter for MuseScore, but I installed them anyway...
sudo dnf debuginfo-install adwaita-gtk2-theme alsa-lib atk avahi-glib avahi-libs bzip2-libs cairo clucene09-core cups-libs dbus-glib dbus-libs elfutils-libelf elfutils-libs expat flac-libs fontconfig freetype GConf2 gdk-pixbuf2 glib2 gmp gnome-vfs2 gnutls graphite2 gsm gstreamer1 gstreamer1-plugins-base gtk2 gvfs harfbuzz ibus-gtk2 ibus-libs jack-audio-connection-kit json-c keyutils-libs krb5-libs libasyncns libattr libbluray libcanberra libcanberra-gtk2 libcap libcom_err libffi libgcc libgcrypt libgpg-error libICE libicu libjpeg-turbo libogg libpng libselinux libSM libsndfile libstdc++ libtasn1 libtdb libtool-ltdl libuuid libvorbis libwebp libX11 libXau libxcb libXcomposite libXcursor libXdamage libXext libXfixes libXi libXinerama libxkbcommon libxkbcommon-x11 libxml2 libXrandr libXrender libxslt libXtst nettle nss-mdns nss-softokn-freebl openssl-libs opus orc p11-kit PackageKit-gtk3-module pango pcre pixman portaudio pulseaudio-libs qt5-qtbase qt5-qtbase-gui qt5-qtdeclarative qt5-qtdeclarative-devel qt5-qtlocation qt5-qtsensors qt5-qtsvg qt5-qttools-libs-clucene qt5-qttools-libs-designer qt5-qttools-libs-help qt5-qtwebkit qt5-qtxmlpatterns sqlite.1 systemd-libs tcp_wrappers-libs trousers xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm xz-libs zlibThen, run MuseScore in gdb. I cancel attempts to restart the previous session, close the Start Center, and then try to open a file by clicking on the folder icon. The results seem pretty similar to the Fedora repo version of mscore:
gdb /PATH/TO/COMPILED/MuseScore-2.0.2/build.release/mscore/mscoreIn reply to Thanks, ABL Running MuseScore by andrewtoskin
OK, so it crashes deep in Qt code, no MuseScore code in sight at all.
Doesn't make it easier to fix...
In reply to Thanks, ABL Running MuseScore by andrewtoskin
@terrycloth:
As Jojo-Schmitz is correctly pointing out, it is crashing inside Qt libraries, so it could be very hard to solve.
It crashes when MuseScore is invoking
new QFileDialog(this);(seen in the previous version of your reply, which points to mscore/file.cpp:812)Sorry if you sent time installing the debug symbols: I think they were not strictly necessary.
I see that a similar problem, but not exactly the same crash, happens here:
https://www.mail-archive.com/qt-creator@trolltech.com/msg04082.html
The solution in that case was to edit ~/.conf/Trolltech.conf
https://www.mail-archive.com/qt-creator@trolltech.com/msg04083.html
and that problem probably stemmed from an upgrade to Qt from 32bit to 64bit version.
That thread was referring to an old version of Qt. For the current version, I think you can try this:
- navigate inside ~/.conf
- rename QtProject.conf to QtProject_back.conf
- try to launch MuseScore and reproduce the crash
- if you still see a crash, if present, you can try to rename also Trolltech.conf to Trolltech_back.conf (but I think this file is not used by newer versions of Qt, so this step is probably useless)
- if the crash is not solved, it is probably better to revert those files to their original name
Hope this helps.
Ciao,
ABL
In reply to @terrycloth: As Jojo-Schmitz by ABL
Aha! Renaming
~/.config/QtProject.conffixed it!Thank you so much, guys. I love MuseScore, and I'm happy to be able to start using it again.
Okay, one more thing: I'd like to try to understand the problem so I can avoid it in the future, or at least figure out how to troubleshoot things myself if the problem comes up again. So, just for my own edification, can you explain what caused the issue with
~/.config/QtProject.confin the first place? Right now I would guess, since I've never directly editedQtProject.confbefore, that maybe the problem had to do with carrying over old configurations from previous Linux installations. Should I be more conservative in which "dot files" I backup when upgrading my OS?In reply to Aha! Renaming by andrewtoskin
I'm glad it worked :-)
Actually, I don't know how the problem originated in the first point. I think you are right in thinking that it could be a remains from an old configuration file.
In principle, if the programs are the same, using the same configuration files should not be a problem. I think that in this case something changed in how the configuration was stored between the two versions of Qt and that originated the crash.
Something similar for example sometimes happened during the development of MuseScore between one Nightly build and the next one, and the solution was of course to delete the old configuration files so that the program itself could write a new one based on its default values. This is one of the reasons why when someone sees a strange/not-yet-reported crash the first advice is usually to reset MuseScore to "factory settings" (with -F).
I know I am not really answering your question, but I don't think there can be general guidelines for these cases.
And if you have further problems with MuseScore, this forum is a great source of help :-)
Ciao,
ABL