Crash when opening MusicXML produced in PhotoScore

• Nov 19, 2014 - 18:49
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore
Tags
musicxml

The attached Music XML file causes both the Beta 2.0 and the nightly build github-musescore-musescore-996902 of MuseScore to crash while importing. 1.3 correctly imports the file. I did not see any obvious problems in the input file by looking at the score that 1.3 produces.

I don't know much about Muxic XML but the problem appears to be in the prolog rather than in the individual parts since deleting text in each of the sections does not stop MuseScore 2.0 from failing to open the file. I believe that I did the text editing correctly because 1.3 parses the edited file and just omits the part I intended to delete.

Attachment Size
Dixit_09_Gloria_Patri.xml 507.53 KB

Comments

• Nov 19, 2014 - 23:54

I am running Windows 7 Service Pack 1. I tried it with the build you specified. I got varying results depending on how I opened the file. It always presented me with the dialog box warning of the invalid date encoding. I always replied yes to the warning box. If I started the program first and then opened the XML file by dragging the file to the main window it behaved as though I had replied no to the warning. (No crash and no new tab.) If I started the program by dragging the file icon to the nightly.exe icon, the nightly.exe process just quietly disappeared from the Task Manager window. If I dragged the file icon to the nightly.exe icon after the task had already been started, I got the "nightly.exe has stopped working" dialog box from Windows.

Reply

• Nov 20, 2014 - 17:50

The warning is caused by the empty encoding-date element, which is correct but harmless as MuseScore does not even read the encoding date.

My version (self-built trunk, a few days old, on OS X 10.7.5) does not crash on this file, nor do I see any obvious problems.

Reply

• Nov 20, 2014 - 18:13

I can't reproduce either using my own build debug version on mac or windows...
But I can reproduce with the most recent nightly on Windows... there might be a difference between a debug and release version... which is not cool :(

Reply

• Nov 20, 2014 - 21:08

This sort of variability in behavior for differences that should make no difference makes me suspect an uninitialized variable. It looks to me as though something in the prolog is missing that causes a variable to be not initialized.

I tried paring down the XML file until MuseScore stopped crashing. I managed to get it to stop crashing with the attached file but with the note element that is in it deleted. If you load the file as is, it should crash but if you delete the element that is bracketed by comment lines, the crash should stop.

Attachment Size
DixitFullTest.xml 667 bytes

Reply

• Nov 21, 2014 - 15:12

I can't reproduce under Linux, even with address sanitizer on.
Attached the backtrace from gdb under Windows. It seems that the crash happens inside function calcTicks due to an "arithmetic exception".
Could it be that in calcTicks(QString text, int divisions), integer divisions is zero for whatever reason?

Attachment Size
xml_crash_gdb_log.txt 1.97 KB

Reply

• Nov 21, 2014 - 15:43

...Mmmmh... It seems that in the original xml file "divisions" tag is set only in measure 9 for all parts except P9 and P10 (where it is set in measure 1).
Could this be the source of the crash?

Reply

• Nov 21, 2014 - 16:30

I don't know much about MusicXML, but running under debugger and settings a breakpoint on calcTicks(), the value being passed in for "divisions" looks to be pretty random for this score. Well, its always 14080223 for me. But with other XML files, it's 8 or 24 or some such.

So I'd say, you've found it! Fix is presumably to provide a reaosnable default value for "divisions", so scores that don't set it themselves (as I assume they are supposed to) don't get random results. But I don't know what that default should be.

Reply

• Nov 22, 2014 - 09:18

Just reviewed all information this thread, including the attachments, and I can confirm that:

- currently the int divisions is not initialized in the MusicXML importer
- it is set only when the first divisions element is read from the MusicXML file
- in the attached file Dixit_09_Gloria_Patri.xml, in parts 1 up to 8, divisions is set in measure 9
- in parts 9 and 10, divisions is set in measure 1
- note that divisions is 4 except in part 5, where it is 12
- in parts 1 up to 8, the duration of measures 1 to 8 is never specified (there are no attributes, the measures only contain a rest of type whole)

All this means that is highly plausible that the crash is caused by using the uninitialized value of int divisions.

Note that fixing this is not simply a matter of initializing divisions with an appropriate default, as no such value exists. Note duration is a fraction defined by both the duration and the divisions element.

Will implement a workaround. Please note that the crash happens only for incorrect MusicXML.

Finally, a fixed version of Dixit_09_Gloria_Patri.xml is attached. Could anyone please verify it opens without crashing on Windows ? I can't as I don't use Windows. The changes in this file are:
- incorrect encoding-date removed
- attributes section in parts 1 to 8 moved to measure 1

Attachment Size
Dixit_09_Gloria_Patri_fixed.xml 509.9 KB

Reply