SegFault when double click Inst Name when load saved instrument

• Mar 17, 2017 - 07:27
Reported version
3.0
Type
Functional
Severity
S2 - Critical
Status
closed
Project

Open attached
piano-flute.mscz

and double click the Flute instrument's name...immediately segfaults:

1 Ms::ScoreView::select scoreview.cpp 3654 0x416523
2 Ms::SelectTransition::onTransition scoreview.cpp 477 0xcfc823
3 ZN20QStateMachinePrivate24executeTransitionContentEP6QEventRK5QListIP19QAbstractTransitionE 0x68c35af4
4 ?? 0x208cc878
5 ??

Although _score has an address...I suspect it is invalid: 0xfeeefeee


Comments

I've reproduced the exact same crash when creating a score from scratch...not even loading the score.

1. my first score
2. edit->instruments
3. add flute
4. in score view, double click on Flute instrument name

crash.

But somehow I can't produce the crash in the official 3.0 nightly build: 4a3864d

Seems a bit sporadic...I managed to reproduce (on my qtcreator debug build) althoguh this time I didn't get a segfault message but rather the following terminal output:

Debug: layoutAll, systems 9 (C:\Users\Eric\Documents\GitHub\MuseScore\libmscore\layout.cpp:3460, void Ms::Score::doLayoutRange(int, int))
Fatal: TextTools::updateTools(): not in edit mode (C:\Users\Eric\Documents\GitHub\MuseScore\mscore\texttools.cpp:147, void Ms::TextTools::updateTools())

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I should note that it involves double clicking one instrument title, then double-clicking the other instrument title, and repeat a few times... (and maybe do other things like wiggle the mouse).

Now I've caught the qFatal crash (I set a breakpoint right before the qFatal)...and here is stack trace:

1 Ms::TextTools::updateTools texttools.cpp 147 0x573474
2 Ms::MuseScore::changeState musescore.cpp 3226 0x494b45
3 Ms::ScoreView::enterState scoreview.cpp 4303 0x41942d
4 Ms::ScoreView::qt_static_metacall moc_scoreview.cpp 216 0x693f2e
5 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68c03046
6 ZN14QAbstractState7enteredENS_14QPrivateSignalE 0x68c663a3
7 ?? 0x292eb708
8 ZN20QStateMachinePrivate9microstepEP6QEventRK5QListIP19QAbstractTransitionEP16CalculationCache 0x68c3ce7e
9 ZN20QStateMachinePrivate10_q_processEv 0x68c3d06d
10 ZN20QStateMachinePrivate13processEventsENS_19EventProcessingModeE 0x68c3d56d
11 ?? 0x2a31c3c0
12 ZN13QStateMachine11eventFilterEP7QObjectP6QEvent 0x68c3d94a
13 ?? 0x29528270
14 ?? 0x29528270

These two errors must be closely related somehow...

I managed to get a single crash (on the first try) with 509693e and steps in comment #3.
And no more despite several tests, with the same nightly, and the current one: 4a3864d
BTW, I note that by double-clicking on the instrument name and then returning to "I", the instruments (eg Piano-Flute) are now considered as parts.

So I've determined that in the following if test in ScoreView::select():

      if (curElement && curElement->score() != _score) {
            _score = curElement->score();
            _score->setUpdateAll();
            _score->update();
            }

That somehow curElement->score() equals the suspicious looking 0xfeeefeee which is not a valid poitner to a score, even though it is not NULL. So trying to figure out why curElement->score() is such a bad value is probably the first set in fixing this bug. Maybe that object was not properly initialized (it should initialize its _score to 0, but maybe it isn't...).

If I Restore previous session that has a two-instrument score, then I can always produce the bug of the bogus curElement if I immediately click on either of the instrument text (without clicking *anywhere* else first)...that will trap me in here and produce the segfault:

      if (curElement && curElement->score() != _score) {
            _score = curElement->score();
            _score->setUpdateAll();
            _score->update();
            }

Per lasconic's suggestion, I halted execution just beofre the _score->update(), and then I set a breakpoint in all the constructors and deconstructors for Text class, then pressed F5, and caught the deconstrucotr happening with stack trace:

1 Ms::Text::~Text text.cpp 926 0x87473e
2 Ms::InstrumentName::~InstrumentName iname.h 28 0xcf638d
3 Ms::InstrumentName::~InstrumentName iname.h 28 0xcf6363
4 qDeleteAll::const_iterator> qalgorithms.h 320 0xb0bb5c
5 qDeleteAll> qalgorithms.h 328 0xb0b436
6 Ms::SysStaff::~SysStaff system.cpp 55 0x866c39
7 qDeleteAll::const_iterator> qalgorithms.h 320 0xb0be45
8 qDeleteAll> qalgorithms.h 328 0xb0b722
9 Ms::System::~System system.cpp 73 0x866d03
10 Ms::System::~System system.cpp 77 0x866dd7
11 qDeleteAll::const_iterator> qalgorithms.h 320 0xb0bd30
12 qDeleteAll> qalgorithms.h 328 0xb0b612
13 Ms::Score::doLayoutRange layout.cpp 3477 0x7d4d43
14 Ms::Score::update cmd.cpp 221 0x8adb3f
15 Ms::ScoreView::select scoreview.cpp 3651 0x4164cc
16 Ms::SelectTransition::onTransition scoreview.cpp 477 0xcfc8d3
17 ZN20QStateMachinePrivate24executeTransitionContentEP6QEventRK5QListIP19QAbstractTransitionE 0x68c35af4
18 ?? 0x208cc878
19 ??

I'm posting here in case I need to analyse this. Most likely this curElement Text object is being created and destroyed in update(), but the curElement pointer is not being updated the new value.

I have seen that instrument text object be destoryed in update and then I've seen it be recreated in Score::collectSystem() call to system->setInstrumentNames(lc.startWithLongNames);

Stack trace for my reference:

1 Ms::System::setInstrumentNames system.cpp 591 0x869481
2 Ms::Score::collectSystem layout.cpp 2722 0x7d0834
3 Ms::LayoutContext::collectPage layout.cpp 3257 0x7d38f0
4 Ms::LayoutContext::layout layout.cpp 3536 0x7d5274
5 Ms::Score::doLayoutRange layout.cpp 3523 0x7d5170
6 Ms::Score::update cmd.cpp 221 0x8adb3f
7 Ms::ScoreView::select scoreview.cpp 3651 0x4164cc
8 Ms::SelectTransition::onTransition scoreview.cpp 477 0xcfc8d3
9 ZN20QStateMachinePrivate24executeTransitionContentEP6QEventRK5QListIP19QAbstractTransitionE 0x68c35af4
10 ?? 0x208cc878
11 ??

I have a feeling that the result is somehow from an unbalancing of startCmd and endCmd.

And I find that normally when clicking something, that there isn't a relayout of entire score.

I also discovered after some combination of clicking/double-clicking the instrument texts and then double clicking the score's title text, that I got another segfault:

1 ?? 0x7547
2 ?? 0x65706c65
3 Ms::Selection::clear select.cpp 297 0x82bcae
4 Ms::Selection::deselectAll select.cpp 274 0x82bbc1
5 Ms::Score::deselectAll score.h 754 0xd04bd0
6 Ms::Score::selectSingle score.cpp 2693 0x81f9af
7 Ms::Score::select score.cpp 2673 0x81f949
8 Ms::ScoreView::select scoreview.cpp 3641 0x416419
9 Ms::SelectTransition::onTransition scoreview.cpp 477 0xcfc8d3
10 ZN20QStateMachinePrivate24executeTransitionContentEP6QEventRK5QListIP19QAbstractTransitionE 0x68c35af4
11 ?? 0x208cc878
12 ??

so even when I just edit title text, that executes startCmd, but not endCmd. But most other operations (such as adding a note) will execute both startCmd & endCmd.

ScoreView::editElementDragTransition() only has a score()->startCmd() but doesn't have a score->endCmd()

...that seems highly suspect... I would think should always be balanced.

EDIT: wait...looks like those startCmd()'s actually seem to be balanced with the endCmd() at the end of ScoreView::select()...

for anyone paying attention, if you want to produce the segfault, you have to double-click the flute instrument name *immediately* after opening piano-flute.mscz (without clicking anything else). And the other bug (the qFatal) involves clicking other things and then alternating double clicking on each of the two instrument titles.

@ericfontainejazz : I can reproduce the crash with the steps in #1 only when using "Single page" view.
Linux Mint 18.1, commit bcbe537
Attached the log from AddressSanitizer. I didn't have time to analyze it in detail yet.
I hope it helps.
Ciao,
ABL

Attachment Size
singlepageview_crash_log.txt 9.21 KB

After further checking, I can reproduce now constantly this issue (bcbe537/ Windows7).

From I observe, I think it’s related to a commit (about layout) which occured a few days ago. Basically, the crash is received by double-clicking an instrument's name, add an element of breaks & spacers (some times, with articulations, eg fermata, barlines, and probably other elements), ) then Undo.

So, new steps from scratch:

1) Create a score for 2 instruments (eg flute and oboe) -> Save/Close/Reload
This test file: Flute - Oboe.mscz

2) Double-click on an instrument’s name (flute or oboe, no matter) -> Escape

3) Add to the score a line break (or section break, or a spacer, etc.) eg in measure 2

4) Undo

Result : crash

So, I can locate the change now, which occured there is three days, on March 14.

- With this nightly, I can double-click on instrument's names, add an element of "breaks & spacers" and Undo without problem: e559a34
- With this one, I receive crashes: d9ff5a2

Note that with this nightly (bcbe537), a shorter scenario, without save-reload, leads also to crash (a variant, or other related/added thing (?) since it does not appear to be directly related to the same commit)

1) Create a score for flute and oboe -> Finish
2) Double-click on an instrument's name (the whole rest must be remained highlighted)
Result: crash
whole.jpg

EDIT: indeed, with this nightly (yesterday: 4a3864d), I can reproduce the issue with steps in comment # 30.
With this one (ed0aaa2), I get an immediate crash after the creation of the score - see steps above-, and also with the "first" scenario after save-reload.

thanks for analaysis!

@ABL I don't think analysis of the address sanitizer output is needed because I'm pretty sure the cause of the segfault is becaue curElement (the selected instrument text) is being destroyed because a layoutAll is triggered (but really it shouldn't)...although I don't understand much of the technical info.

@cadiz I'm unable to reproduce your sets nor am I able to reproduce my original crash on 3.0-dev 3543170 on arch linux Mate. Note that I reported this crash on Windows 10...there possibly might be something different going on with windows, I dont know...

I mentioned to lasconic in chat that I think werner or someone else will have to fix this because I don't understand much of the 3.0 code involved.

You are really unable to reproduce a crash with the file and steps in comment # 30, and bcbe537 ?
(just tried again a few minutes ago on Windows 7 and Windows 10: same repetitive crash here)

Recall steps:
1) Load this file: Flute - Oboe.mscz
) Double-click on an instrument’s name (flute or oboe, no matter) -> Escape
3) Add to the score a line break (or section break, or a spacer, etc.) eg in measure 2
4) Undo
--> Crash

@cadiz, I'm still unable to reporduce a crash from your steps and file from #34. I'm on arch linux MATE desktop.

DISREGARD.. I just realized my master branch is old on this machine...I forgot to rebase!!!!

Strange...I've rebased to latest master and recompiled on my Arch MATE machine, but I can't repoduce from your steps... I'm on same revision bcbe53783.

Also I'm able to reproduce the qFatal...

But I can't reproduce my segfault either.

Could be some difference between linux and windows low-level system calls.

oh wait...I just producec a segfault on arch linux from my original instructions. Although it appears to be a different stack trace from windows:

1 raise 0x7fffeb569a10
2 abort 0x7fffeb56b13a
3 __gnu_cxx::__verbose_terminate_handler vterminate.cc 95 0x7fffebb824ed
4 __cxxabiv1::__terminate eh_terminate.cc 47 0x7fffebb802a6
5 std::terminate eh_terminate.cc 57 0x7fffebb802f1
6 __cxxabiv1::__cxa_pure_virtual pure.cc 50 0x7fffebb80e5f
7 Ms::ScoreElement::isNote scoreElement.h 314 0xb3e075
8 Ms::MuseScore::endCmd musescore.cpp 4594 0xcce0dc
9 Ms::ScoreView::select scoreview.cpp 3657 0xb2f434
10 Ms::SelectTransition::onTransition scoreview.cpp 477 0xb4180d
11 QStateMachinePrivate::executeTransitionContent(QEvent *, QList const&) 0x7fffec161cdd
12 QStateMachinePrivate::microstep(QEvent *, QList const&, CalculationCache *) 0x7fffec16bde2
13 QStateMachinePrivate::_q_process() 0x7fffec16bfe2
14 QStateMachinePrivate::handleFilteredEvent(QObject *, QEvent *) 0x7fffec16c92c
15 QStateMachine::eventFilter(QObject *, QEvent *) 0x7fffec16ca2d
16 QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject *, QEvent *) 0x7fffec1011a1
17 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7ffff3c1f325
18 QApplication::notify(QObject *, QEvent *) 0x7ffff3c278c5
19 QCoreApplication::notifyInternal2(QObject *, QEvent *) 0x7fffec101440
20 QApplicationPrivate::sendMouseEvent(QWidget *, QMouseEvent *, QWidget *, QWidget *, QWidget * *, QPointer&, bool) 0x7ffff3c260cd
...

Status (old) active fixed

I cannot reproduce: indeed, fixed "by default", since this commit/nightly 14324a6, which desactivates the previous feature (introduced for the 2.1) for making instrument names editable.