Crash on load after converting flam grace notes and re-creating slurs; dangling slur startElement references saved

Issue type

Crash or freeze

Description with steps to reproduce

Crash on reopening score after changing grace-note flam notation and re-creating slurs

Environment

• OS: Windows 11 Version 25H2 or later
• Architecture: x86_64
• MuseScore Studio: 5.1.0-260820080, 64-bit
• Revision: github-musescore-musescore-3fc3942

Summary

MuseScore Studio crashes immediately while loading a score that had previously been opened successfully, edited, and saved.

There is no error dialog, warning, recovery prompt, or other visible diagnostic. MuseScore simply terminates during score loading.

The score was later analyzed outside MuseScore. The .mscz archive itself was valid, and the embedded MuseScore XML files were syntactically well-formed. The problem appears to have been caused by invalid internal references involving slur objects whose starting note/chord elements no longer existed.

Removing only those invalid slur objects allowed the score to open normally again.

Background

This score appears to have originated in an earlier version of MuseScore.

I believe, with approximately 80% confidence, that the attached older file is the original score that was imported into MuseScore Studio 5 before the edits that led to the crash.

The probable original file contains:

<museScore version="3.01">

The subsequently edited/crashing file contains:

<museScore version="5.00">

The instrumentation and opening musical structure correspond closely between the two files.

The score contains marching percussion notation, including flam figures.

After opening/importing the older score in MuseScore Studio 5, I corrected the flam notation.

The original flams used 16th-note grace notes. I changed the affected grace notes to 8th-note grace notes with slash and corrected/re-created the associated slurs.

The score appeared normal after editing and saved without any reported errors.

After closing MuseScore, however, the next attempt to open the saved .mscz file caused MuseScore Studio to crash immediately during loading.

Editing sequence

The sequence that led to the problem was approximately:

1. Open/import a score originally created in an earlier MuseScore version.
2. Locate existing flam notation in the percussion staves.
3. Change an existing 16th-note grace note to an 8th-note grace note with slash.
4. Correct, remove, or re-create the slur associated with the grace note/flam.
5. Repeat this operation for multiple flam figures.
6. Save the score.
7. Close MuseScore.
8. Reopen the saved .mscz file.

Actual result

MuseScore crashes immediately while loading the saved score.

There is:

• no warning,
• no parsing error,
• no damaged-score message,
• no recovery dialog,
• and no indication of which score element caused the failure.

Expected result

The score should reopen normally.

At minimum, if the file contains an invalid internal reference, MuseScore should ignore or reject the affected element and report the problem rather than terminating the application.

File analysis

The .mscz container itself was not corrupted.

The ZIP archive could be opened normally and its contents extracted successfully.

The embedded MuseScore XML files were also syntactically valid and well-formed.

The failure therefore appears to be semantic/internal-reference corruption rather than XML syntax corruption.

In the main score, 10 slur objects were found whose startElement references pointed to note/chord objects that no longer existed.

The Snare Line excerpt contained the same type of problem, also involving 10 dangling slur start references.

The Bass and Tenor excerpt XML did not show the same invalid references.

In simplified terms, the saved score contained relationships equivalent to:

Slur -> startElement -> missing/deleted note or chord

The referenced start element was no longer present in the score data, but the slur object referencing it remained serialized in the saved file.

This left the XML itself valid while the MuseScore score object graph was internally inconsistent.

Recovery test

A repaired copy of the crashing score was created by removing only the slur objects containing the invalid start-element references.

No notes, rhythms, measures, instrumentation, layout, or other musical content were intentionally changed.

The repair removed:

• 10 invalid slur objects from the main score
• 10 corresponding invalid slur objects from the Snare Line excerpt

The .mscz archive was then rebuilt.

The repaired file opens successfully in MuseScore Studio.

This strongly suggests that the crash occurs while MuseScore is loading or resolving a slur/spanner whose referenced start element does not exist.

Comparison with the probable original file

The probable original MuseScore 3 file and the crashing MuseScore 5 file appear closely related.

The instrumentation matches:

• MDL Snare Line
• MDL Tenor Line
• MDL Bass Line 5

The corresponding instrument IDs also match:

• mdl.drum.snare-drum
• mdl.drum.tenor-drum
• mdl.drum.bass-drum

The opening rhythmic structure also corresponds closely.

In the older MuseScore 3 file, the relevant grace notes are represented as grace16.

In the MuseScore 5 file, the corresponding edited figures are represented as acciaccatura.

That is consistent with the actual editing operation performed: changing 16th-note grace notes to slashed 8th-note grace notes and correcting/re-creating the associated slurs.

Because the broken slur references appear both in the master score and in the Snare Line excerpt, it seems possible that the invalid slur objects were already present in MuseScore's in-memory score model before the file was serialized.

Possible areas to investigate

The exact cause is not known, but the failure may involve the interaction between:

• importing/converting an older MuseScore score,
• changing an existing grace-note type or duration,
• replacing an existing grace note,
• deleting or re-creating a slur,
• slur/spanner start/end element bookkeeping,
• excerpt/part synchronization,
• serialization of removed score elements,
• and deserialization of a spanner whose referenced element cannot be resolved.

One possibility is that replacing or converting the grace note removes or replaces the original note/chord object while an older slur/spanner continues to reference its former element ID.

Another possibility is that the visible slur is correctly replaced in the UI, but an obsolete slur object survives internally and is written during save.

A defensive validity check during score loading may also be useful so that a dangling spanner reference cannot crash the application even if the underlying save-time bug remains.

Files attached

I am attaching three files:

1. Probable original MuseScore 3 score

   • Opens normally.
   • Believed to be the score before import/editing.

2. MuseScore 5 score that crashes on load

   • Produced after editing the flam grace notes and associated slurs.
   • Crashes MuseScore Studio immediately when reopened.

3. Repaired MuseScore 5 score

   • Same score, except the invalid slur objects were removed.
   • Opens successfully.

These three files provide a probable before/failure/repaired comparison set.

Note about this report

This issue report was prepared collaboratively by the user and ChatGPT.

The user supplied the score files, editing history, MuseScore version/build information, and observed crash behavior.

ChatGPT assisted with examining the internal .mscz/XML structure, identifying the dangling slur references, producing the minimally repaired file, comparing the probable original and crashing files, and organizing the technical findings in this report.

The conclusions above are based on that file comparison and should be treated as diagnostic findings rather than a confirmed identification of the exact source-code defect.

Score.zip

Supporting files, videos and screenshots

musescore_crash.zip

https://github.com/user-attachments/assets/c8688781-8fcc-4222-a541-d422b9c793f8

In which versions of MuseScore Studio is this issue present?

MuseScore Studio version (64-bit): 5.1.0-260820080, revision: github-musescore-musescore-3fc3942

Regression

I was unable to check

Operating system

OS: Windows 11 Version 25H2 or later, Arch.: x86_64

Additional context

No response

Checklist

• This report follows the guidelines for reporting bugs and issues
• I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• I have attached all requested files and information to this report
• I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible