Opening file causes crash
Just in case it is only me I thought I'd open a thread here rather than an item in Issue Tracker.
With recent versions of MuseScore nightly build if I attempt to open any score on my machine the application crashes. Launching MuseScore does open the example file but after that a file open results in an immediate crash.
Revision dc5679f does work but every Mac nightly build from 63c50d5 onwards suffers the same problem. I have tried resetting preferences to default and completely removing MuseScore from my machine before installing but nothing I do seems to resolve the problem for the last couple of days of builds.
I'm using Mac OS X 10.6.8 which is fully up to date.
Comments
Hi
Could you supply a score that does this?
In reply to Hi Could you supply a score by chen lung
Is there some way I can send you a file privately? The "Contact" form doesn't seem to have a facility for attaching files. Unfortunately I don't have any scores at the moment which are free from copyright so can't post any of them to the forum.
If not I'll see if I can create a test file to replicate the problem
In reply to Is there some way I can send by brod
Are the files created with MuseScore 1.2? If yes, you can mail me the file (my nickname at gmail.com). If they are created with a nightly, there is big announcement everywhere that it can happen with nightlies and that MuseScore nightlies are not compatible in any ways together. You can try to export to MusicXML from the working version to another one.
In reply to Are the files created with by [DELETED] 5
They are not created with 1.2.
I realise version 2 is not stable and changes can break things. I posted the comment because I couldn't see anything in the documented changes over the last couple of days which mentioned anything about changes in file format or format version numbers. None of the files are important enough to particularly bother about although it is inconvenient to have to create files from scratch to try out the latest builds.
Since you mention a "big announcement everywhere" saying that nightly builds are not compatible with each other, by which I assume you mean files made with one are not necessarily compatible with others, I had a look because I hadn't seen anything worded like that before - although as I said I understand these builds are not stable and are not meant to be relied on and only looked because of the wording of your post. Even having searched I can't find anything along those lines.
In reply to Are the files created with by [DELETED] 5
Just out of curiosity I attempted to export to MusicXML as suggested as I've not tried this functionality before. The export seemed to succeed, no errors and a file created.
Attempting to open the file in the most recent nightly it was reported as not being a valid MusicXML file. Choosing to go ahead and attempt to load the file anyway MuseScore crashed. Of course this is a different problem but a problem nonetheless as it should fail more gracefully.
The version which opens the original .mscz file successfully also crashes when attempting to open the same MusicXML file.
In reply to Just out of curiosity I by brod
Maybe we should do a better job explaining the compatibility issue. What we have right now. The splash screen mentions that it's an unstable version. The download page mentions "Use at your own risk". So indeed, maybe it's not big enough.
Can you share the MusicXML which give validation errors?
In reply to Maybe we should do a better by [DELETED] 5
I've just sent you the MusicXML file by email. It is copyrighted material and I don't own the copyright so please don't post it.
The fact that the nightly builds are untested, unstable and to be used at the tester's own risk are all clear. It was the implication that every version should be considered incompatible with every other which I was having problems understanding. I would expect changes in file format to be planned and therefore probably mentioned somewhere and I hadn't managed to find the mention of a change. Even if I couldn't go back to the working version I have no issue with losing the files although one was exhibiting a problem which I hoped had been fixed in a recent commit which was the main reason for trying to open it with so many versions.
In reply to I've just sent you the by brod
Thanks for the MusicXML file, it looks like MuseScore generates non valid XML in a special case. The problem comes from rests and the export on their vertical position on the staff. There are several of them. The first one is measure 13, staff 2, voice 3, a 16th rest, on the 3rd beat. Could you tell if this rest has something special, regarding its vertical position? If yes, could you try to make a simple one measure score with the same problem?
In reply to Thanks for the MusicXML file, by [DELETED] 5
Thanks for looking at the file.
I'll move back to a version where I can open the .mscz file and have a look tomorrow.
Quite a lot of the scores I produce have 3 or 4 voices and the rests often have to be moved to make them readable. I'll see if I produce a test file and post again with the results.
In reply to Thanks for the MusicXML file, by [DELETED] 5
Here's a one measure score which produces the problem. I've noticed a lot of strange behaviour whilst trying to produce this so have only simplified it to the point of isolating the measure.
The test .mscz file does not open in the latest nightly build, it crashes the program just like the full score does. I did my testing with revision dc5679f as I needed to be able to open the original file to see what it was.
For completeness, here are some of the oddities I came across trying to create this file.
1. Selecting measure 1 with the mouse then selecting measure 12 in the same way whilst holding shift then choosing "delete selected measures" from the Edit - Measures menu deletes 13 measures not 12 even though only 12 were visibly selected and the cursor had been nowhere near measure 13. Selecting measure 12 first then measure 1 deleted the expected 12 measures.
2. After removing the first 12 measures, selecting measure 2 (the original measure 14) followed by the last measure caused a crash as soon as I clicked on the last measure. Selecting in reverse as above removed the section as expected.
3. Saving the single measure which was left as a new .mscz file changed it! The original measure after cutting is as below (I've used a page break to stretch it to full width of the page for ease of comparison
![before]( "before")
![after]( "after")
After saving the file using File - Save As I was left with
The vertical position of the rests is unchanged but the clef has been changed so the notes have moved and are now obscuring the rests. The key signature has also disappeared and accidentals inserted instead.
When I looked at your reply last night I did not think about the significance of staff 2 but as you can see, it's tablature so does not have any (visible) rests. If there are invisible rests inserted (which do not show even with "show invisible" enabled) their positioning is entirely managed by MuseScore.
In reply to Here's a one measure score by brod
I have discovered the problem opening files is not just because of differences between the builds, it seems to be a bug.
I have just recreated a test file using revision 178ca82 by manually entering the measure posted as test_1 (but with the correct clef and key signature) and have saved it as test_2.mscz. I then exported it as a MusicXML file test_2.xml.
Attempting to open the xml caused MuseScore to crash. Using 178ca82 it doesn't even give a warning that the xml isn't valid it just crashes straight away. The difference seems to be with the file as it causes an immediate crash with the older revision dc5679f which gives a warning with the first test file submitted.
Even though 178ca82 was used to create the .mscz file in the first place, attempting to open that file with revision 178ca82 also causes an immediate crash. It can be opened successfully with the older build.
In reply to I have discovered the problem by brod
Sorry for the repeated posts which are likely to be triggering multiple emails but I've been coming back to the problem to look at it again and now have more information.
I've concentrated on the beat causing the problem in the first file I sent and have found that the following steps will consistently cause a crash:
1. Create new file with linked staves with one being a tab
File - New
Click "Next"
Expand "Guitars", select "Guitar" and click "Add" button
Select "Stave 1" in right-hand pane and click "Add Linked Staff" button
Click "Next" twice and then "Finish" to exit the wizard
Right click a measure in the second staff, select "Staff Properties"
Click on "Type" dropdown and change to "Tab"
Click "OK"
2. Enter a triplet which starts with a rest in the pitched staff
Click in the first measure of the first staff and then the "N" button to enter note entry mode
Select the rest icon from the toolbar and enter it in the measure.
Press "Esc" to exit note entry mode
From Notes - Tuplets menu choose "Triplet" (MuseScore may crash at this stage but if it doesn't carry on - I think it does not crash if you deselect the rest entered and then select it again before creating the tuplet)
Leave the first rest of the triplet and enter any notes in place of the second and third rests
Press "Esc" to exit note entry mode
3. Save and reopen file
Save file and close
Attempting to open the file you have just saved will cause MuseScore to crash
I've not raised an issue yet (to avoid potential duplication of effort). There seem to be a fair number of tuplet issues but from what I can see nothing relating to rests in tuplets.
Since it is not possible to save a file with a tuplet created as described it may not be exactly the same problem as the one in the submitted test files but it certainly seems to be related.
In reply to Further findings by brod
File test_1.xml is invalid because it contains a null character as value in the display-step for a rest at line 712. I still don't understand how this can be generated by the MusicXML exporter. I cannot debug the issue, as the current trunk crashes for me when reading most files containing a linked staff (including your attached files). For this crash, I submitted issue #19164: Consistent crash reading file with linked staves, which may or may not explain why test_2.xml crashes.
In reply to File test_1.xml is invalid by Leon Vinken
Issue 19164 is very likely the problem that I first reported when I started this thread which started with build 63c50d5. At the time I did not spot the crash might be caused by a problem with linked staves because all my scores have linked staves which I suspect is why I can't open any of them.
Since the problem with the XML file seems to predate the problem of the crash, would it not be possible to debug that with version from before 25th November?
In reply to Issue 19164 is very likely by brod
Probably, but I'd rather spend my time going forward, thus I prefer to wait for issue 19164 to be solved. After that I can debug the XML issue.
In reply to Probably, but I'd rather by Leon Vinken
You've probably noticed but the linked staff crashing problem has now been fixed.
In reply to You've probably noticed but by brod
Yes, using the current trunk I can load both testfiles test_1_0.mscz and test_2_0.mscz. When exported as MusicXML, the resulting test_1_0.xml is invalid due to a null character. Both test_1_0.xml and test_2_0.xml cause MuseScore to crash on import.
I don't know the cause of either issue yet, but will investigate. No committed end date yet.
In reply to Yes, using the current trunk by Leon Vinken
Found the cause for the invalid MusicXML, see #19218: [MusicXML export] invalid display-step and display-octave for moved rests on tablature staff. Will be fixed shortly.