Trying to add text to a vertical/horizontal frame after double click causes crash

• Feb 9, 2020 - 11:05
Reported version
3.4
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

Double-click a vertical frame (insert or append one first if needed)
Ricght-click into it to try adding any text

-> crash

Workaround is of course not to double-click that frame...

Comments

• Feb 9, 2020 - 11:11

Stack trace:
1 Ms::TextBase::endEdit textedit.cpp 75 0x98f0ba
2 Ms::ScoreView::endEdit editelement.cpp 162 0x51beb8
3 Ms::ScoreView::changeState events.cpp 1127 0x6512d7
4 Ms::ScoreView::mousePressEvent events.cpp 556 0x64f345
5 ZN7QWidget5eventEP6QEvent 0x27e3717f
6 ?? 0x364ed320
7 ?? 0x89000000
8 ?? 0xb0458dc3
9 ?? 0xcca1c189
10 ?? 0xff0215d5
11 ?? 0xebd889d0
12 ?? 0x24048900

Reply

• Feb 9, 2020 - 16:20

When running with undefined behavior sanitizer, I see the following error (just before the crash):
/media/antonio/Mint0/MuseScore_addresssanitizer/libmscore/textedit.cpp:75:39: runtime error: member access within null pointer of type 'struct TextEditData'

I don't know if the problem is maybe related to the cause of #300635: Crash when using palette item upon a staff-text , since that bug involves also TextEditData

Reply

• Feb 10, 2020 - 09:55
Title Trying to add text to a vertical frame after double click causes crash ⇒ Trying to add text to a vertical/horizontal frame after double click causes crash

Text frame is not affected, just vertical frame and horizontal frame

Reply

• Mar 25, 2020 - 09:18
Status PR created ⇒ fixed

Fixed in branch master, commit 9c017b7c0c

_fix #300855: Trying to add text to a vertical/horizontal frame after double click causes crash

The crash is caused by ed.getData(t) failing and returning nullptr, where t is the newly added text element and ed is the score edit data. The interesting thing is that this didn't return nullptr when not in edit mode already before adding the text - it was only a problem when adding text when already in edit mode. The line of relevance that is the root of this whole problem is, in ScoreView::changeState:

if (s == state)
return;

where s is the new state and state is the current one. This is right at the start, so if we're already in edit mode, then the crucial startEdit() call further down the function won't happen. Of course, startEdit is the bit that's responsible for clearing the edit data and adding the new edit data for the new text element. So, when it doesn't run, there's no edit data for the new text. And when there's no edit data, getData fails. And when getData fails, text->cursor(ed) crashes on a Q_ASSERT._

Reply

Fix version
3.5.0