CRASH album when remove score with TBox, after first joining
On x86-64 ArchLinux both 2.0.3 and master a65f06b. Replication steps:
- create a score "My_First_Score-withtextbox" which is just like "My_First_Score" but has an extra text box after the title textbox, before Measure 1.
- create an albums of scores:
- My_FirstScore.mscz
- My_First_Score-withtextbox.mscz
- My_First_Score
- join scores
- now in album manager, select the 2nd score "My_First_Score-withtextbox" and delete it
Result: SEGFAULT with following callstack:
1 Ms::TBox::~TBox textframe.cpp 45 0x13041d4 2 Ms::TBox::~TBox textframe.cpp 46 0x1304222 3 Ms::Score::~Score score.cpp 419 0x1269143 4 Ms::Score::~Score score.cpp 437 0x12697d0 5 Ms::AlbumItem::~AlbumItem album.cpp 38 0xdbf1e0 6 Ms::Album::remove album.cpp 365 0xdc106d 7 Ms::AlbumManager::removeClicked albummanager.cpp 190 0xdc3040 8 Ms::AlbumManager::qt_static_metacall moc_albummanager.cpp 116 0x101128c 9 QMetaObject::activate(QObject *, int, int, void * *) 0x7fffef484870 10 QAbstractButton::clicked(bool) 0x7ffff05082f2 11 ?? 0x7ffff0276484 12 ?? 0x7ffff0277937 13 QAbstractButton::mouseReleaseEvent(QMouseEvent *) 0x7ffff0277ab4 14 QWidget::event(QEvent *) 0x7ffff01c0a58 15 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7ffff017c68c 16 QApplication::notify(QObject *, QEvent *) 0x7ffff0182071 17 QCoreApplication::notifyInternal2(QObject *, QEvent *) 0x7fffef458518 18 QApplicationPrivate::sendMouseEvent(QWidget *, QMouseEvent *, QWidget *, QWidget *, QWidget * *, QPointer&, bool) 0x7ffff0180e45 19 ?? 0x7ffff01da919 20 ?? 0x7ffff01dce6b ...
Attachment | Size |
---|---|
My_First_Score-withtextbox.mscz | 6.53 KB |
My_First_Score.mscz | 6.46 KB |
Comments
Very interesting...in TBox::~TBox(), when it deletes the first TBox and the second TBox, I notice that _text is exactly the same address both time. Similarly for staticMetaObject. The only address that changes between the first and second TBox deletion is the this pointer.
Well I can reproduce the crash with just using an album of two scores, with these steps:
result: crash
well here minimal test case which produces crash:
https://github.com/ericfont/MuseScore/commit/66d0fcc2379869badc7d776689…
Doesn't need an entire score...all needs is a text box in 2nd or later. It seems somehow _text is deleted twice somehow...both when the join happens (when discard later scores after joining) and when either removing the score from album list, or when exiting album manger.
Solution was to allocate a new Text object during TBox::clone().
https://github.com/musescore/MuseScore/pull/2534
Fixed in branch master, commit ea7714af41
fix #105621 CRASH album when remove score w/ TBox
This fixes a crash that occured during the TBox deconstructor.
When generating an album, there joined scores have their measures cloned into the first score. However, the TBox clone constructor did not allocate a new Text object when performing the clone, but rather only simply copied the pointer address. Hence, when the Album::createScore() would delete the score, that original Text object would be deleted. But then the second time that score was deleted, that corresponding TBox would have _text pointing to an previously-deleted Text object. The solution I've done is to allocate a new Text object during clone.
Fixed in branch master, commit 202f9579bd
Merge pull request #2599 from lasconic/105621-textbox-deconstructor-crash2
fix #105621 CRASH album when remove score w/ TBox
needed in 2.0.4 too?
Fixed in branch 2.0.4, commit 91afbb2228
fix #105621 CRASH album when remove score w/ TBox
This fixes a crash that occured during the TBox deconstructor.
When generating an album, there joined scores have their measures cloned into the first score. However, the TBox clone constructor did not allocate a new Text object when performing the clone, but rather only simply copied the pointer address. Hence, when the Album::createScore() would delete the score, that original Text object would be deleted. But then the second time that score was deleted, that corresponding TBox would have _text pointing to an previously-deleted Text object. The solution I've done is to allocate a new Text object during clone.
Automatically closed -- issue fixed for 2 weeks with no activity.