Crash when adding text in a score containing middle beam on a rest

• Jun 4, 2019 - 01:02
Reported version
3.1
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project

Simply add a subtitle to this score and >>boom!<<.
Details:
- MuseScore-3.1.0-x86_64.AppImage on Linux (debian stable with a few additions from debian testing).
(Version 3.0.1, Revision e26f7c4)

  1. Bring up Musescore.
  2. Open the score.
  3. Add > Text > Subtitle
  4. Type some text into the now-open subtitle text box. (I recommend "boom!")
  5. Click somewhere else on the page, or hit esc to finish the insertion.
  6. If you still see a musescore running, complain to me and I'll try to do a better job.

Incidentally, there seem to be a lot of other things in this score that can crash the program. This was the simplest and most repeatable one I found though. (Playing with text in the title area seems to generally kill it fairly quickly though.)

This is a new bug in 3.1, and it does exist in the latest dev build (MuseScoreNightly-201906031353-master-8c42b37-x86_64.AppImage). However, I can edit the score safely (including adding a subtitle) in 3.0.5.

Attachment Size
Ave_Maria_crashes.mscz 22.15 KB

Comments

Title Crash when adding subtitle (and many other title area text edits) Crash when adding text in a score containing middle beam on a rest
Frequency Once

From scratch:

1) Create new score
2) Enter a single eighth note on first beat
3) in "Beams" palette, double-click Middle Beam
Result (I don't recall exactly, but not expected I guess ? At least, different behavior with the 2.3.2):
So, a beam is added
beam.jpg
4) Enter a text (on the note/a rest), or enter lyrics, chord symbols, figured bass etc.
5) Escape, or Undo

-----------> crash

This is similar to #282333: Crashing on lyric entry in that items added to the undo stack during layout interfere with the way text edits are combined into a single undoable command. But do these items belong on the undo stack in the first place? I think not.

This particular crash can be prevented by changing one line in ChordRest::removeDeleteBeam() from

      score()->undoRemoveElement(b);

to

      score()->removeElement(b);

Similarly, the crash in #282333: Crashing on lyric entry could have been prevented by simply changing two lines in Chord::layoutStem() from

      score()->undoAddElement(hook);

and

      score()->undoRemoveElement(hook());

to

      score()->addElement(hook);

and

      score()->removeElement(hook());

instead of changing the way that text edits are rolled back.