SegFault when double click Inst Name when load saved instrument
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 actually don't know why this wasn't happening before...let me double check on an official windows nightly build.
No crash in 2.1 (when forcing it to open there)
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
a Heisenbug?
DEBUG vs. RELEASE build?
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:
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).
I've set a breakpoint in texttools.cpp line 147 and will see if I catch this error in the debugger.
Text::startEdit() sets edit mode to true.
Text::endEdit() sets edit mode to false.
So somehow it might still be in edit mode when it should be...
ok, just reproduced the segfault by loading the score, but it didn't hit my breakpoints I set...so maybe it missed setting the edit mode (or something)
_score is still set to the suspicious looking 0xfeeefeee as it was when I first reported this segfault.
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.
thanks cadiz for verifying.
I can't seem to reporduce in 2.1-dev 3543170 try as I might double-clicking for a few minutes.
@cadiz's I've verified the bug you found in #12 and spun it off as a separate issue: #182011: double-clicking on Instrument Text in scoreview will cause Edit->Instrument to display name as "Part"
So I've determined that in the following if test in ScoreView::select():
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...).
both curElement's _score and _links is set to that suspicious looking 0xfeeefeee.
Basically all of curElement's members look bogus:
I'm willing to bet that the act of double-clicking on the Instrument Name Text is not properly setting curElement to a valid object.
the line just before that if block seems to be the problem:
_score->update();
It changes curElement from a nice Text object into a bogus object.
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:
it seems after that _score->update(), all the memory that is pointed to by curElement is set to a long string of 0xee 0xff repeated...
exactly 368 bytes of 0xee 0xfe
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
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
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
...
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.
Automatically closed -- issue fixed for 2 weeks with no activity.