Persistent crash on playback

• Nov 25, 2017 - 02:19

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

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 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 RepeatList
despite 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 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 by Nicolas

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?

Attachment Size
mscore-msgs.txt 33.08 KB

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.

Do you still have an unanswered question? Please log in first to post your question.