File causes Musescore to crash!
I have a file that causes MuseScore 2.1.0 Revision 871c8ce to crash.
It reports that the last 2 measures are incomplete (0/1 not 4/4) but as soon as I click my mouse anywhere on those measures (trying to delete) MuseScore crashes.
I am attaching the file - "Telstar"
Running on Win7 Pro and it is updated.
| Attachment | Size |
|---|---|
| Telstar.mscz | 19.65 KB |
Comments
Repaired file: Telstar1.mscz
Have you an idea how this file is in this state? (ie the two last corrupted measures)
Have you some steps to reproduce? Or what did you exactly made "around" these two last measures, what was your aim?
Eg why you do invisible one barline at this location, what was the goal?
Or have you cut something, or copy/paste (with parts or not, and multimeasure rests or not?)
There is something strange here
I have had this piece for years. Originally scanned by SharpEye and used in Musescore 1.1
By the fact that the last 2 measures are still there, I might not have been able to delete them before.
Ver 2.1 reported a number of errors because (.)s had been missed in the scan. Previous versions didn't complain and I had never noticed their omission (Measures 25,29,33,35,42 & 43). I Cleaned them up but can't do anything about the last 2 measures. JUST HAD AN IDEA...
OKAY! I was able to append a measure to the end (doesn't require me to click anywhere) and then I was able to delete the last FOUR measures! I just need to append the last measure back in!
That helps me but doesn't solve the problem.
Since it is something to do with the end of the file, I am assuming it should be relatively easy to fix. Just thought it was worth taking the time to report. Obviously not a major problem.
Also note that this is a problem with importing XML files. Musescore doesn't check for syntax and it is easy to miss the dot after a note on scanned music. I am impressed that it now allows me to ADD the dot BUT in some cases I still have to duplicate the measure and delete the old one because it carries the note over into the next measure - even though it clearly only has 3/4 not 4/4 rythm!
"I have had this piece for years.
Originally scanned by SharpEye and used in Musescore 1.1"
Ah, indeed, it does a lot for a single file! This could explain this, or in part. And so, my idea is that it is not really useful to further investigate.
Especially since, as you say, it is easily to fix.
Unless otherwise stated (the one who disagrees will be able to make it re-ascend as an active bug), I propose to close it.
Of course, if you can reproduce a similar issue from a file created with 2.1, you are prompted to report it. Thanks.
I was just more concerned that it might manifest itself in other ways. Clearly something is not working properly with the "end-of-file" condition. Next occurrence might be harder to track down and fix.
But, yes. Close by all means. There should be enough keywords here for this solution to show up in future searches, yeah?
Thanks
"Clearly something is not working properly with the "end-of-file" condition."
What do you mean exactly? What'is clearly?
"I was just more concerned that it might manifest itself in other ways."
How?
A file of two years involving SharpEye and the "older" 1.1 is not a proof that this issue might manifest now in other ways with the last version.
Maybe you don't know, but there had been some/many issues like this, solved in particular for the 2.1
Perhaps some corner cases are always present, but I am rather confident about the rest.
So, have you an idea for reproduce with this version? We need steps for this. This is what matters.
Regardless of how the corrupt file was created, MuseScore cannot deal with it. Ergo, there is some condition at end-of-file that it does not expect or cater for. Thinking like a programmer... ;)
Right, think like a programmer, those do need steps to reproduce the problem from scratch or some other clear indicators. There don't seem to be any hre, so let's close, and reopen if new information is available
In reply to Right, think like a… by Jojo-Schmitz
If you want user's assistance you have got to remember not to "shoot them down in flames"!! I provided you with a file to re-create this BUG and it is very simple to see. I took time to report this, as I said, because I see it as a fairly simple example of a bug that may manifest itself in other, more complicated ways later. AND be harder to reproduce. Before you can debug a program you HAVE to convince yourself that it has errors. Simple, basic rule of programming that too many (so called) programmers seem to ignore today!
I will not waste my time in future.
Thanks.
Well, nobody shot doan anybody here. The file you provided was corrupt and originally got created with a pretty old version of MuseScore (which did not detect nor report such corruptions, this is a 2.x feature), it got further edited with 2.1 (at least it got last saved with 2.1). With that file anything can happen, you can't expect a program to deal "properly" with any broken file. You even got your file repaired!
The real question is: how did that file get into that condition. Die the 1.1 file show that behavoir already? Do you still have that and can provide it here?
The current development build crashes on loading that file already, BTW.