changing instruments from Mixer and close without saving cause crash

• Apr 25, 2016 - 17:46
Reported version
3.0
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Create a new score from scratch with Nightly 994090f.
Open it;
Changing instrument from Mixer;
Close without saving;
Crash.

994090f (on Vista)

Attachment Size
TestN.mscz 3.25 KB

Comments

• Apr 25, 2016 - 19:49

Close the score, not musescore. Confirmed on Windows 7

Stack trace:
1 Ms::Score::masterScore score.h 932 0xc1ffe8
2 Ms::MuseScore::setCurrentScoreView musescore.cpp 1410 0x486338
3 Ms::MuseScore::removeTab musescore.cpp 1935 0x487fe5
4 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 798 0x687eeb
5 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68a07a62
6 Ms::ScoreTab::tabCloseRequested moc_scoretab.cpp 186 0x68e2ef
7 Ms::ScoreTab::qt_static_metacall moc_scoretab.cpp 94 0x68dfeb
8 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68a07a62
9 ZNK7QTabBar18minimumTabSizeHintEi 0x1943cf73
10 ?? 0x1
11 ?? 0x28c8c8

Seems to crash when it tried tu update the mixer, but there's no score to update it with, so I guess it would not crash when either there's another score open, or the mixer gets closed before the score.

Hmm, the former helps, the latte does not. Why is ''mixer' not 0, when there is no mixer open? Is a delete missing?

Reply

• Apr 26, 2016 - 10:24

With this change:
{syntaxhighlighter }
diff --git a/mscore/musescore.cpp b/mscore/musescore.cpp
index 883269b..e2a6f45 100644
--- a/mscore/musescore.cpp
+++ b/mscore/musescore.cpp
@@ -1407,7 +1407,7 @@ void MuseScore::setCurrentScoreView(ScoreView* view)
if (selectionWindow)
selectionWindow->setScore(cs);
if (mixer)
- mixer->updateAll(cs->masterScore());
+ mixer->updateAll(cs ? cs->masterScore() : nullptr);
#ifdef OMR
if (omrPanel) {
if (cv && cv->omrView())

{/syntaxhighlighter}
it doesn't crash right away, but later or instead open an existing score, change instrument via mixer, close without saving and BANG!
Stack trace:
1 ?? 0xfeeefeee
2 Ms::RemoveElement::cleanup undo.cpp 1588 0x732902
3 Ms::UndoCommand::cleanup undo.cpp 133 0x72bcd8
4 Ms::UndoStack::~UndoStack undo.cpp 196 0x72c0bc
5 Ms::MasterScore::~MasterScore score.cpp 4060 0x749caa
6 Ms::MasterScore::~MasterScore score.cpp 4064 0x749d75
7 Ms::MuseScore::removeTab musescore.cpp 1943 0x488090
8 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 798 0x687efb
9 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68a07a62
10 Ms::ScoreTab::tabCloseRequested moc_scoretab.cpp 186 0x68e2ff
11 Ms::ScoreTab::qt_static_metacall moc_scoretab.cpp 94 0x68dffb
12 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68a07a62
13 ZNK7QTabBar18minimumTabSizeHintEi 0x1985cf73
14 ?? 0x1
15 ?? 0x28c8c8

Doesn't happen with all scores, just some, and I haven't yet found the common denominator. Maybe this is an entirely different issue?

What puzzles me is stack frames #5 and #6, I don't see why/where in #6 we call #5, which is in the same function a few lines up. Some recursion going on?

Reply

• Apr 26, 2016 - 10:39
Status (old) active ⇒ patch (code needs review)

I still have crashes with some of my existing scores, still trying to find the common denominator, but the problem descibed in this issue seems fixed by my PR. But without my PR these scores crash with the stack trace of #2, so it does seem to be related.
There are so many issues with current master that lead to crashes, that it is pretty hard to tell them apart.

Reply