Crash on adding text on a text frame (MS 3.5 Alpha, debug build)

• May 10, 2020 - 18:52
Reported version
3.x-dev
Priority
P2 - Medium
Type
Development
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

1) Create new empty score (just treble staff).
2) Select a measure.
3) menu -> Add -> Frames -> Insert Text Frame
4) click on newly created text frame
5) crash

Crash is on the Q_ASSERT in textedit.cpp, line 133. Both variables in assert, newlyAdded and textWasEdited are false.

Comments

• May 11, 2020 - 03:29

FWIW doesn't seem to crash for me with the alpha, not terribly surprising if it's just an assertion failure, but often those lead to crasehs even in release builds.

Reply

• May 11, 2020 - 07:04
Status needs info ⇒ active

It is a self build 3.5 Alpha with debug, that's why the assert in my case caused a crash.
However, looking in the code:
// If this assertion fails, no undo command relevant to this text
// resides on undo stack and reopen() would corrupt the previous
// command. Text shouldn't happen to be empty in other cases though.

So maybe it's not a "real" crash but a potential corruption of the undo stack. Not sure what the severity should be then.

Reply

• May 11, 2020 - 07:29

Doesn't stress the fact that it happens only in a debug build, not in the release and probably not in an MSVC RelWitDebInfo one, so others would waste their time hunting a phantom in trying to repropuce ;-)

Reply

• May 11, 2020 - 08:01

It looks like logically the assertion actually does not fail here: this text has actually been just added to a score as a part of this text frame. The issue is that usually text elements are added separately while in text frames Text object is created automatically by the frame (TBox) and does not have a separate undo stack entry. This is what confuses this assertion (and the code which handles undo stack entries here). Probably TextBase::endEdit() code should ideally be also able to treat the case when text gets added as a part of another element (apparently I missed this case when I added this code here), but it should be also safe to treat TBox case in a special way and consider the text be newly added if it is added as a part of TBox as well.

Reply

• May 28, 2020 - 23:52

Fixed in branch 3.x, commit 252534dff8

_fix #305253: fix assertion failure on adding text frame with no text

An alternative to 18e625bda704adfc7b0135a626f167e51217ba90 way to
fix the assertion failure. The solution in this commit does not try
to remove the text belonging to text frame (as it is managed by text
frame itself) and does not try to modify undo stack further in case
of adding empty text frame._

Reply

Fix version
3.5.0