musescore 2.0 segfault in mscore/seq.cpp:643
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 :)
The state can be TRANSPORT_PLAY if jack is playing.
I protected the function against a null score in b412a80c34
Oh I see, TRANSPORT_PLAY refers to *jack's* transport state, not mscore's.
Confirmed fixed, cheers.
Automatically closed -- issue fixed for 2 weeks with no activity.