Crash when deleting header/footer text after hiding

• Oct 16, 2020 - 00:55
Reported version
3.5
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

Steps to reproduce:

  1. Open any score and select the header, footer or page numbers.

  2. Press V to hide the text.

  3. Press Delete to delete the text, and MuseScore crashes. This only occurs once the text has been hidden, unhiding it and deleting it will still produce the crash.

It's also worth noting that
A. header/footer text doesn't visually update to be hidden until you click off of it, and
B. it is currently impossible to delete header or footer text at all using Delete, even before hiding it.

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.13199, revision: 43c5553

Comments

• Oct 16, 2020 - 07:54
Frequency Many ⇒ Few

Crash confirmed, with MuseScore 3.5.1
I can confirm A) too, please file as a separate (and Minor) issue
B) might be by design, but if so MuseScore shouldn't allow this at least not crash on the attempts

Reply

• Oct 16, 2020 - 08:58

Stack trace:
1 Ms::ScoreElement::isTBox scoreElement.h 276 0xfe1fb0
2 Ms::Score::deleteItem edit.cpp 2025 0x916d80
3 Ms::Score::cmdDeleteSelection edit.cpp 2514 0x919bb3
4 Ms::Score::::operator()(Ms::Score *, Ms::EditData &) const cmd.cpp 4170 0xadad84
5 std::_Function_handler>::_M_invoke(const std::_Any_data &, Ms::Score *&&, Ms::EditData &) std_function.h 316 0xaed20a
6 std::function::operator()(Ms::Score *, Ms::EditData&) const std_function.h 706 0x105461d
7 Ms::Score::cmd cmd.cpp 4197 0xadcb91
8 Ms::ScoreView::cmd scoreview.cpp 2831 0x5fe983
9 Ms::ScoreView::cmd scoreview.cpp 2077 0x5f6bf3
10 Ms::MuseScore::cmd musescore.cpp 6646 0x432e1a
11 Ms::MuseScore::cmd musescore.cpp 6068 0x42f6df
12 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 523 0x5a408c
13 QMetaObject::activate(QObject *, int, int, void * *) 0x68a947c8
14 Ms::ScoreTab::actionTriggered moc_scoretab.cpp 225 0x5c280a
15 Ms::ScoreTab::qt_static_metacall moc_scoretab.cpp 110 0x5c2292
16 QMetaObject::activate(QObject *, int, int, void * *) 0x68a947c8
17 QActionGroup::hovered(QAction *) 0x2add4db2
18 QActionGroup::qt_static_metacall(QObject *, QMetaObject::Call, int, void * *) 0x2add573c
19 QMetaObject::activate(QObject *, int, int, void * *) 0x68a947c8
20 QAction::activate(QAction::ActionEvent) 0x2add3e0e
...

Reply

• Oct 16, 2020 - 09:21

Seems a simple one-line fix that prevents the crash. It won't allow deleting items from the header/footer though (which might be the right thing to do anyhow).

diff --git a/libmscore/edit.cpp b/libmscore/edit.cpp
index 038cc8f09..89774a6fb 100644
--- a/libmscore/edit.cpp
+++ b/libmscore/edit.cpp
@@ -2022,7 +2022,7 @@ void Score::deleteItem(Element* el)
                   break;
 
             case ElementType::TEXT:
-                  if (el->parent()->isTBox())
+                  if (el->parent() && el->parent()->isTBox())
                         el->undoChangeProperty(Pid::TEXT, QString());
                   else
                         undoRemoveElement(el);

But: a double-click on any element for the footer but the page number doesn't bring up the Format > Stils > Header/Footer dialog, as it does without that change.

Reply

• Oct 16, 2020 - 09:34

OK, works much better with this change:

diff --git a/libmscore/edit.cpp b/libmscore/edit.cpp
index 038cc8f09..0907c7cd0 100644
--- a/libmscore/edit.cpp
+++ b/libmscore/edit.cpp
@@ -2022,7 +2022,7 @@ void Score::deleteItem(Element* el)
                   break;
 
             case ElementType::TEXT:
-                  if (el->parent()->isTBox())
+                  if ((el->parent() && el->parent()->isTBox()) || el->isTBox())
                         el->undoChangeProperty(Pid::TEXT, QString());
                   else
                         undoRemoveElement(el);

But still double-clicking am element in header/footer that had been made invisible doesn't work, i.e. doesn't bring up that dialog, instead it pretends to edit that text (but really doesn't.
This isn't different from the behavior before the change though, so I guess that is the way to go then

Reply

Fix version
3.6.0