Opening file leads to crash in 3.0
Saul A2 - S1 - 8 Sinfonia_2.mscz
I saved this file, closed it and reopened it almost immediately and MuseScore 3.0 alpha, OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 26ad655 immediately crashed.
The mscx file is in tact and my xml viewer doesn't complain about the file when I open it. I'm not yet familiar with the new mscx format so I don't know where the problem might be.
The backup file crashed also.
Comments
The crash happens while trying to add the Skyline for a Beam that has no beam segments. I am not sure why there would be a beam with no beam segments, but adding
at the beginning of Beam::addSkyline() will prevent the crash.
In reply to The crash happens while… by mattmcclinch
I don't self compile MuseScore, so I can't add that.
Does that mean that there was an error writing to score to disk? Can the error be fixed in the .mscx file so I can open it? If so, I just need to know where in the file and how to fix it so I can open the file. I can then edit the measures so the error is not repeated and then we can try to figure out what went wrong so it doesn't happen again.
In reply to I don't self compile… by mike320
I fixed your score so that you can open it. See the attachment. The beam properties for 3 different groups of 16ths had gotten corrupted. I am not sure what caused that to happen, but it occurred in measures 7 and 13, in "Violins II" and "Violins I,II", which are both marked as invisible.
In reply to I fixed your score so that… by mattmcclinch
I know what was happening in those measures. I made the beams horizontal using the inspector and move the beam between the first and second notes in each of these situations. Measure 7 is the measure I reported #276139: Using Inspector after leaving edit mode causes crash. in. To work around this issue, I adjusted one beam, saved, closed and reopened the file, then changed the other beam and save the file immediately since it didn't crash. I then continued working on the file and the next section had fewer instruments, so I hid the instruments I didn't need for that section with the intention that I would unhide all needed instruments once the file was complete. I found that my score caused a crash when I tried to start working on the score this morning.
Thank you for fixing the file. I hope all of this information will help to track down the bug.
In reply to I fixed your score so that… by mattmcclinch
I'm curious how you determined the problem as in measures 7 & 13. Did the debugger tell you or is there some encrypted way the .mscx file tells you what measure you are in. I wanted to see the offending measures so I could find this problem in the future if someone has the problem, but I don't see any measure info in the 3.0 file.
In reply to I'm curious how you… by mike320
I have access to the MuseScore source code, and I can modify it at will. I can add debug information, insert breakpoints, disable lines of code, etc. Eventually, I found the right place to have it tell me what I wanted to know.
In reply to I'm curious how you… by mike320
Regarding knowing what measure you are in by looking at the file, I guess this is one of the changes made to make it easier to compare two scores to identify differences. The idea being that it would be nice if merely inserting or deleting a measure didn't make all subsequent measures show as different due to their measure numbers. It was acknowledged this would make hand-editing MSCX files awkward. There may or may not be an option to force extra info into the file for that purpose?