musescore 2.0 segfault in mscore/seq.cpp:643

• Jun 19, 2013 - 02:59
Type
Functional
Severity
S2 - Critical
Status
closed
Project

On git commit b1d7b217ba1a6ebe3c845f4f0b4b7226e84740df

I've managed to get musescore into a state where it segfaults every time I run it. The splash screen appears but isn't rendered, so it's fairly early on.. I'm trying to use JACK audio (mscore -a jack), and had a look at the problem in GDB:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe3be6700 (LWP 11425)]
Ms::Seq::process (this=0x7fffe56ff010, n=n@entry=1024, 
    buffer=buffer@entry=0x7fffe3be3dc0)
    at /home/sqweek/tmp/src/MuseScore/mscore/seq.cpp:643
643	                  if (cs->playMode() == PLAYMODE_SYNTHESIZER) {
(gdb) print cs
$1 = (Ms::Score *) 0x0

If I'm reading the code correctly, this is within a "if (state == TRANSPORT_PLAY) {" block, so somehow the transport state has been persisted in PLAY mode and it's trying to play before a score has been loaded?

I'm not exactly sure how I got here, but I do remember killing a previous instance of mscore with SIGINT (ctrl-c) when it started eating memory and causing my machine to swap. I think I had just turned off jack MIDI (which I used to use in 1.2) in an attempt to try out the internal synth with Jack output.


Comments

Further details:

"mscore -a asdf" displays an error "no audio driver found" and loads successfully
"mscore -a jack -F" also loads successfully, but after quitting and restarting the segfault returns
"mscore -a alsa" and "mscore -a alsa -F" get a different segfault during startup, during Qt initialisation :/

I'm running archlinux, kernel 3.9.4-1-ARCH
jackd version 0.121.3 tmpdir /dev/shm protocol 24
extra/alsa-lib 1.0.27.1-1

OK I cleared the problem with the following steps:

1) start with "mscore -a jack -F"
2) Start playing the score
3) Stop playing the score
4) Quit mscore
5) now "mscore -a jack" starts up fine

so looks like the saved transport state was the culprit.

"mscore -a alsa" still segfaults but that's a seperate bug I guess

Is there any reason to save the transport state at all?

I doesn't really make sense to me on the desktop, though maybe it's appropriate for mobile platforms...

If by transport state you mean (play/pause) and by "save", you mean saved between sessions, so after a restart of MuseScore. I'm pretty sure that MuseScore doesn't save it.

Yes, that's what I meant. But if it isn't saved in the first place, I guess I need a new explanation for the bug :)