Crash on certain operations involving file containing very large "slide" elements spanning multiple pages
- Import the attach XML
- Check for glissandi, esp. measure 57, rehearsal mark G, Mellophone, there should be none
- Switch to Continuous mode
- Check for gliss again. see above, not there is one, extending to the last measure of the score
- 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
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".
OK, then it relates to #270643: [EPIC] MusicXML import/export issues
In reply to (No subject) by Jojo-Schmitz
Removing all be the last slide "start" element seems to prevent the crash, but removing all but the first doesn't.
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
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 ?
A slide fom B4 to F#4 doesn't seem unreasonable to me?
Or do you mean the span over 37 measures?
In reply to A slide fom B4 to F#4 doesn… by Jojo-Schmitz
Indeed I did mean the 37 measures.
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.
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.
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.
Pull request https://github.com/musescore/MuseScore/pull/5815
I fixed a similar crash from another issues (https://musescore.org/en/node/292631)
See https://github.com/musescore/MuseScore/pull/5874
My solution not only fixes the crash, but also fixes the rendering, it is drawn as it should, and not at the top of the page. :)
The pull request has been merged.
igor.korsukov's, that is.
Automatically closed -- issue fixed for 2 weeks with no activity.