Crash on certain operations involving file containing very large "slide" elements spanning multiple pages

• Jun 7, 2019 - 16:25
Reported version
3.1
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore
Tags
musicxml
  1. Import the attach XML
  2. Check for glissandi, esp. measure 57, rehearsal mark G, Mellophone, there should be none
  3. Switch to Continuous mode
  4. Check for gliss again. see above, not there is one, extending to the last measure of the score
  5. Either save as MSCZ or switch to Page mode

-> Crash

Stack trace:
1 std::vector::end stl_vector.h 591 0xe14050
2 Ms::System::firstMeasure system.cpp 1002 0x94aedd
3 Ms::Glissando::layout glissando.cpp 277 0x8512f1
4 Ms::LayoutContext::collectPage layout.cpp 4370 0x88cbd9
5 Ms::LayoutContext::layout layout.cpp 4564 0x88dccc
6 Ms::Score::doLayoutRange layout.cpp 4550 0x88dbcc
7 Ms::Score::doLayout layout.cpp 4405 0x88cee4
8 Ms::Score::createThumbnail scorefile.cpp 508 0x9bb115
9 Ms::Score::saveCompressedFile scorefile.cpp 592 0x9bb95f
10 Ms::Score::saveCompressedFile scorefile.cpp 497 0x9bb071
11 Ms::MuseScore::saveAs file.cpp 1930 0x645b59
12 Ms::MuseScore::saveAs file.cpp 2427 0x6497d8
13 Ms::MuseScore::cmd musescore.cpp 5941 0x4f5ef4
14 Ms::MuseScore::cmd musescore.cpp 5735 0x4f4f25
15 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 855 0x40a1d6
16 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68c81805
17 ZN12QActionGroup7hoveredEP7QAction 0x26694ee5

Workaround: either stay in Page mode, or save as mscx or delete that glissando

No crash when switching to single page mode

No such crash in MuseScore 2.3.2, so a regression, not sure though about 3.0.5

Attachment Size
forum.xml 2.49 MB

Comments

• Jun 7, 2019 - 16:56

The XML file contains what appear to me to be invalid "slide" elements (these import as glissando). I'm no expert, but I see 5 slide "start" elements and only one "stop".

Reply

• Jun 7, 2019 - 16:57
Title Crash when saving XML import as MSCZ or switch to Page mode, when switched to continuous mode before ⇒ Crash on certain operations involving MusicXML file containing possibly invalid "slide" elements

Reply

• Jan 24, 2020 - 14:19

Still crashes in latest master

1 std::vector::end stl_vector.h 591 0xe70b9c
2 Ms::System::firstMeasure system.cpp 1015 0x978e0b
3 Ms::Glissando::layout glissando.cpp 277 0x877ad1
4 Ms::LayoutContext::collectPage layout.cpp 4303 0x8b4ed4
5 Ms::LayoutContext::layout layout.cpp 4508 0x8b5fa3
6 Ms::Score::doLayoutRange layout.cpp 4496 0x8b5f01
7 Ms::Score::doLayout layout.cpp 4338 0x8b51de
8 Ms::MuseScore::switchLayoutMode musescore.cpp 6562 0x42e19c
9 Ms::MuseScore::switchLayoutMode musescore.cpp 6547 0x42dffd
10 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 504 0x5fe8ba
11 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68c82e55
12 ZN25QComboBoxPrivateContainer15mousePressEventEP11QMouseEvent 0x27eebeb8

Reply

• Mar 9, 2020 - 07:04

Result of quick investigation:
- the problem is caused by the Mellophone part (which contains five slide starts and one slide stop)
- removing all other parts does not solve the problem
- removing all slides solves the problem
- the MusicXML import creates a single slide from the B4 in the 1st beat of measure 57 to the F#4 in the 2nd beat of measure 94

I suspect the failure mechanism is the glissando layout code that cannot handle such a big slide (note: there is no reason for it to support that !), but this is triggered by the way the current MusicXML importer handles malformed slides: it simply connects the first slide start with the first slide stop that follows.

Proposed solution is to have the importer check the slide start and stop notes are in a reasonable range. I assume this means in consecutive notes, does anyone know of corner cases where that would not be true ?

Reply

• Mar 12, 2020 - 20:53

Actual crash mechanism is that cr2->segment()->system() is null in Glissando::layout() when switching from continuous to page mode, causing a crash (at the if statement below "FINAL SYSTEM-INITIAL NOTE"). Still do not understand what is causing this and if it is related to MusicXML import at all.

Reply

• Mar 13, 2020 - 06:39

Getting closer to the cause. This is indeed not MusicXML related. Reproduce as follows:
- open attached attached file (created in MuseScore, containing a large slide spanning many measures)
- add a page break somewhere (I used measure 4)
- notice how the slide segments incorrectly move to the top of the page (!)
- save
- notice same crash occurs
Looks like the root cause is related to having a page-spanning slide, which still begs the question: should the MusicXML importer generate these on receiving weird or incorrect input ?
Note that I am not familiar with the code where all of this happens and have no idea what the real underlying bug is.

Attachment Size
large_slide.mscz 10.98 KB

Reply

• Mar 14, 2020 - 07:19
Title Crash on certain operations involving MusicXML file containing possibly invalid "slide" elements ⇒ Crash on certain operations involving file containing very large "slide" elements

Reply

• Mar 14, 2020 - 08:28
Title Crash on certain operations involving file containing very large "slide" elements ⇒ Crash on certain operations involving file containing very large "slide" elements spanning multiple pages

Simply returning immediately from Glissando::layout() when cr2->segment()->system() is null prevents the crash and is similar to the existing error handling of Spanner::Anchor::NOTE in SLine::linePos(). As far as I can tell, this does not lead to any further issue.

Will submit a pull request with this change.

Reply

Fix version
3.5.0