Persistent crash on playback
Description of bug:
Starting playback frequently causes MuseScore to crash.
Details:
This bug appears randomly and cannot be reliably reproduced. Sometimes it occurs when I start playback immediately after opening a score. More often, it occurs when I start playback after making a change. The type of change doesn't matter; it can be adding or subtracting note, inserting or deleting dynamics, or altering some feature of the layout, e.g. changing the curve of a slur.
I have noticed that saving after every change, no matter how trivial the alteration, seems to keep MuseScore from crashing as often, but the strategy is not reliable.
I am not able to run MuseScore in debugging mode because it crashes immediately upon opening a score with
time 0.000000 not found in RepeatList
Aborted (core dumped)
I'm attaching the output from /var/log/kern.log, which shows MuseScore segfaulting during calls to libstdc++. The quantity of segfaults is an indicator of how frequently the problem occurs.
I'm also attaching a sample score in progress that exhibits the bug. The playback will sound awful since I use LinuxSampler rather than MuseScore's internal synthesizer. Also note that this is an .mxcz copy of the .mscx file I actually work on.
System details:
Intel quad core, 2.67 GHz, 64 bit architecture
3.9 gig RAM
Kubuntu 16.04 with KXStudio repo enabled
4.4.0-101-low-latency Linux kernel
KDE Plasma desktop 5.5.5
Audio components:
jackd 0.124.2, started with Cadence
MuseScore 2.0.3
LinuxSampler 2.0
Non-mixer 1.2
Jamin 0.97.14
| Attachment | Size |
|---|---|
| kern.log_.txt | 10.2 KB |
| Mutterlos-worksheet-score.mscz | 85.37 KB |
Comments
I don't know how to help you :(
Here it seems to work safely (Vista/2.1 or Nightly ce9ffd8).
In reply to I don't know how to help you… by Shoichi
No new?
Not really any idea.
. I can open the file within and without the debug mode, without any crash. At least with OpenSuse and without setting up Jack.
For me it sounds similar to https://musescore.org/en/node/230606.
Not sure for the reason and whether upgrading to 17.10 or testing it on a other distribution (maybe inside a virtual machine or as a second operating system beside the existing) would be useful. And this would take much time, so maybe someone other knows perhaps a simpler solution.
Maybe it could also be useful to ask for this problem (edit: ;) in an Ubuntu forum (also for https://musescore.org/en/node/230606).
In reply to Not really any idea… by kuwitt
note: can't also reproduce yet by switching from XFCE to Plasma.
Does it also crash when you try with the internal Fluid synthesizer? (without using Jack or any of its add-ons)
In reply to Does it also crash when you… by Ziya Mete Demircan
Yes, it does. Furthermore, instead of a crash that causes MuseScore to exit completely, I'm sometimes experiencing playback getting "stuck." When I start playback, the vertical blue cursor appears at the correct spot, but nothing further happens and MuseScore becomes completely unresponsive. I have to kill it from the terminal.
I'm not seeing any movement on this bug. I can't even find it in the issue tracker list. I have been fighting an uphill battle with MuseScore because of it since at least July 2017, when I filed a similar bug report.
For fun (?) today, I ran
less kern.log kern.log.1 kern.log.2.gz | \
egrep -c 'mscore[[:print:][:space:]](segfault|general protection)
to see how many times MuseScore crashed in the past week. Seventy-five times! In each case, it's a call to libstdc++ causing a segfault, as shown in the kern.log file I attached to the original post.
I used ftrace(1) to verify that the crash is coming from the main executable, not a child process, and that is, indeed the case. Unfortunately, ftrace doesn't provide any sort of debugging information.
This is a critical bug, and it surprises me, as an open-source developer myself, that it is being ignored. I have lost hundreds of hours of working time to it. Some days, it takes four or five attempts to get playback without a crash--and that's before I've even started editing the score.
Since MuseScore will not run in debug mode, core dumping with
time 0.000000 not found in RepeatListdespite that particular bug having been tagged Fixed=>closed, I can provide no further information, and very much need to hear from someone knowledgeable about what steps I can take to provide it.
I am not able to test with nightly build AppImages because playback is disabled in them. Neither can I install Qt5.8 in order to build from the git repo without creating hell throughout my entire system.
In reply to I'm not seeing any movement… by Peter Schaffter
As an open source developer yourself, I'm sure you are aware that it's easier to fix a bug that can be reproduced. In this case, we have not much information except for "time 0.000000 not found in RepeatList".
Are you still running MuseScore 2.0.3 ?
Which bug are you talking about when you say it's closed? Why are 2.2 nightly AppImage not working? Which version of Qt can you have without breaking your system?
In reply to As an open source developer… by [DELETED] 5
Concerning your opening comment, I couldn't agree more. It's exquisitely ironic that I find myself in this position.
Answering your questions in reverse order, I currently have a stable Kubuntu 16.04 system with qt5.5.1 and qt4.x installed alongside it (package dependencies require it). Replacing qt5.5 with 5.8 breaks some dependencies.
The 2.2 nightlies do work, but not for playback through JACK. Since I use JACK exclusively and this bug affects playback, the nightlies are useless for testing purposes.
The bug I'm talking about is https://musescore.org/en/node/25954, dealing with MuseScore crashing in debug mode. It's supposed to be fixed, and is one of the reasons I can't provide more information than I have.
I'm still running 2.0.3, stock install from Kubuntu 16.04.
The "time 0.000000 not found in RepeatList" comes from MuseScore running in debug mode (per the node mentioned above) and isn't related to the crash-on-playback bug that's plaguing me, which is a segfault during a call to libstdc++.
The only other information I can gather is by running MuseScore from the command line and capturing the messages sent to the terminal. The attached text file contains the messages spat out during a single launch/load file/hit playback run that crashed. There are a ton of slurs and hairpins "not found." I doubt these have anything to do with playback crash, but who knows?
In reply to I'm not seeing any movement… by Peter Schaffter
Isn't it possible to configure the sound settings inside the AppImages of the nightly builds on your system for further investigation or testing?
I'm using an AppImage nightly from time to time and never had problems with the playback.
In reply to Isn't it possible to… by kuwitt
I don't think playback is a problem, but using AppImages with jack is, see #105901: ARM AppImage needs to work with non-pulse systems (ALSA-only or Jack)
In reply to I don't think playback is a… by Jojo-Schmitz
Probably you're right.
In reply to I don't think playback is a… by Jojo-Schmitz
If I'm not wrong, there is a workaround by using Jack1 instead of Jack2, see comment: https://musescore.org/en/node/105361#comment-810181 in #105361: AppImage does not work with Jack Audio - SOLVED.
But it sounds, if it works with 2.0.3, but not with versions afterwards - but maybe it's worth for testing (?).
In reply to I don't think playback is a… by Jojo-Schmitz
Precisely.
Found it! The bug is in the JACK transport implementation. When JACK transport is enabled, the bug, as described, never occurs. When it is enabled, the bug occurs--randomly but frequently, as noted--when playback is started from within MuseScore after making changes to the score.