Changing instrument names may lead to crash and empty mscz file

256 bytes is way to short and nobody would be able to fix this. And indeed looking into the file shows no score whatsoever.
However, check https://musescore.org/en/node/52116, hopefully you find a backup that is useful enough.

Well, it'd help if you could come up with a series of steps that reproduce the problem, and do so not just on your machine.

So you weren't actively doing anything when the crash happened? If so, that suggests the crash happened during the auto-save operation. We just found one such crash that happens if you have a score with linked parts and one of the parts has multiple staves (eg, for piano) and you try deleting one of the staves. I don't suppose you had just done anything like that? If not, posting the backup copy you did find could still be helpful, as maybe we'd see something unusual in your score that would suggest something to us.

Well, it pretty much *has* to be either something specific to the score, or something specific to the actions you were taking. Otherwise, it would constantly be crashing for everyone :-). Well, it's also possible it is something specific to your system - something about your audio drivers, say, or anti-virus software. But anyhow, any information you can provide that would help us understand what might have happened increases the chances we can identify and fix the problem. Otherwise, there is literally nothing we can do - no place to even begin an investigation.

Darnit! This happened to me too now, twice! I can't reproduce, but I know what I did.

I made a change on some notes, played it, quickly hit spacebar to stop playback and then hit Ctrl + S to save. The result: 0kb file

This is happening here too. A lot. I've lost already many many hours of work due to different segmentation faults in MuseScore 2.0.X. It happens during a Ctrl+S during random moments, random scores, I couldn't really isolate the problem. Result is the same reported above: a 0k file. The syslog below shows a set of segfaults that happened during a few hours of work today:

[91602.057784] mscore[16947]: segfault at 0 ip 0000000000ca227f sp 00007fffd0beffe0 error 4 in mscore[400000+15f7000]
[91657.089460] mscore[17257]: segfault at 0 ip 0000000000ca227f sp 00007fff10791c80 error 4 in mscore[400000+15f7000]
[99626.123194] traps: mscore[17269] general protection ip:ce05f0 sp:7ffe0d63cbf8 error:0 in mscore[400000+15f7000]
[105067.456832] traps: mscore[18354] general protection ip:ce05f0 sp:7ffec48b6c98 error:0 in mscore[400000+15f7000]
[105212.488695] QXcbEventReader[19275]: segfault at 7f6f918d7aa9 ip 00007f6f918d7aa9 sp 00007f6f8fb3eca0 error 14 in locale-archive[7f6f91967000+189000]
[105389.580157] QXcbEventReader[19318]: segfault at 7f9011de0af6 ip 00007f9011de0af6 sp 00007f9010047ca0 error 14 in locale-archive[7f9011e70000+189000]
[106998.971028] QXcbEventReader[19957]: segfault at 7f5302406aa9 ip 00007f5302406aa9 sp 00007f530066dca0 error 14 in locale-archive[7f5302496000+189000]

I'm using MuseScore 2.0.2 in a Debian system.

We'd still need precise steps to reproduce

But you should never lose hours of work due to a crash. Musescore autosaves every two minutes, and you can increase that to every minute if you like. So that is te most work you should ever lose. Next time you start MuseScore, it will prompt you to restore the previous session. Say yes, and you are back to within a minute or two of where you were last. If you need furthet help with crash recovery, please ask in the Support forum.

But if you ever find steps to reproduce a crash, please file a new bug report here with the specific score and precise steps to reproduce the problem so we can try to fix it.

So tiagovaz is on Debian with 2.0.2. Which operating system are the others on who experiences this bug?

Hi Marc, in such cases when I click "yes" to recovery it says the file can't be opened. Then I see the file has a 0 byte size. And I was unable to find a recent version of it inside my ~/.local/share/data/MuseScore/MuseScore2/. Next time it happens I'll try to grab more details. Thanks.

So it happened again. Crashed during a Ctrl+S, then got 0byte mscz file. Then I went to ~/.local/share/data/MuseScore/MuseScore2/ and tried to find the backup file, with no success (no mscz from Oct 28):


-rw------- 1 tiago tiago 43432 Oct 21 21:12 scKM5534.mscz
-rw------- 1 tiago tiago 27915 Oct 21 21:13 scXU5534.mscz
-rw------- 1 tiago tiago 27915 Oct 21 21:15 scR27139.mscz
-rw------- 1 tiago tiago 46956 Oct 21 21:15 scM27139.mscz
-rw------- 1 tiago tiago 46954 Oct 21 21:17 scN27217.mscz
-rw------- 1 tiago tiago 46956 Oct 21 21:21 scc27310.mscz
-rw------- 1 tiago tiago 24413 Oct 23 13:48 scLi1593.mscz
-rw------- 1 tiago tiago 33516 Oct 25 19:00 sctg5075.mscz
-rw-r--r-- 1 tiago tiago 81 Oct 28 19:16 plugins.xml
-rw-r--r-- 1 tiago tiago 122 Oct 28 20:59 session

Segfault entry in syslog:

[83815.146585] traps: mscore[29444] general protection ip:ce05f0 sp:7ffe6e839e88 error:0 in mscore[400000+15f7000]

My setup is for auto-save each 5 minutes. It seems I've lost hours of work again. Please give some priority to this issue. I'm going to report a "serious" bug in Debian BTS to avoid this version going to testing/stable.

Thanks,

I'm happy I could recover the file from my owncloud server, which had sync'ed about 1 minute before the crash! I'm attaching the mcsz which should be in the same state it was right before the crash, hope that helps.

@tiagovaz I opened your score on Mac OS with 2.0.2, toyed a bit with it, saved it a few times but I didn't manage to crash MuseScore, nor did I get an empty file. I'm afraid we are looking for the exact steps to reproduce this crash. It could be hard though as it may be a memory leak.

Just asking: did you encounter this problem ever since you started using Owncloud? Maybe MuseScore writing the file and Owncloud trying to sync the file causes some race condition on your box?

@Thomas Interesting! I was indeed using OneDrive as my backup service so maybe syncing is a problem!

Somewhat unrelated: OneDrive SUCKS as backup service cause you don't have file versions (for anything else than Microsoft files), so if MuseScore saves a 0kb file and OneDrive uploads it within seconds... you are screwed. Use Dropbox or possibly Google Drive

MuseScore does save a hidden backup of the previous saved version, though: https://musescore.org/en/node/52116

So it seems that the common denominator between both of you (tiago & Sti2nd ) is that you are using a syncing service and the result is a 0kb file. Not sure how to proceed with this knowledge. Is it a MuseScore problem?

I have not experienced this with another program or other files.

Let us say it is not Musescore related at all. Then one would think that those syncing services would work hard to fix this, if it happens with several programs... One would actually believe that if such things had been reported to these syncing services it would have been fixed already, or else this is a secret they try to hide, cause it makes their service practially useless :o

I tried to search for the last option. Hard to search in their "bug tracker", couldn't do it at all actually... could only search for ideas. Found one other post on google about 0kb file.

From now I'll be saving my work out of the ownCloud storage and will let you know if these segfaults go away.

ps: as I can remember, I moved to this solution after having lost some work due to other kinds of segfault in MuseScore, but it seems I made things worse.

Thanks for keeping track of it.

So I confirm that having working files away from my ownCloud sync directory this issue is gone.

However, it seems a bug in MuseScore anyway. I use other softwares which save (and auto-save) files in my ownCloud sync dir and never experienced such issue :\

Thank you for confirming Tiago. When you check the revision history of the synced mscz file on ownCloud, can you suddenly see a 0kB file?

I guess we can assume that the crash and empty mscz file can be reproduced by:
* using MuseScore on Debian with ownCloud
* have auto save in MuseScore enabled
* work on a rather large score? Or no difference here?

I'm sorry to say that it has just happened again while I was not using owncloud nor any other sync service :(

It happened twice today. Same issue. Auto-save is not working at all, at least it's not saving anything in /home/tiago/.local/share/data/MuseScore/MuseScore2/

Recent segfaults:

[387316.117478] traps: mscore[16404] general protection ip:ce05f0 sp:7fff9dd06488 error:0 in mscore[400000+15f7000]
[387610.725716] QXcbEventReader[17495]: segfault at 7f53bb9d1aa9 ip 00007f53bb9d1aa9 sp 00007f53b9c38ce0 error 14 in locale-archive[7f53bba61000+189000]
[391731.781818] musescore[21090]: segfault at 20 ip 0000000000c9a710 sp 00007fff895bfda8 error 4 in mscore[400000+159d000]
[391819.329886] QXcbEventReader[21356]: segfault at 7f773408b839 ip 00007f773408b839 sp 00007f77322efce0 error 14 in locale-archive[7f7734169000+189000]

How can I debug in a more helpful way?

Just thinking aloud in case it rings any bell to anyone.

It is strange that one GP is for a process named "mscore" and another segfault is for a process called "musescore". As far as I can tell from my machine (which runs Linux Mint 17.2, though), MuseScore process is called "mscore"; so where the other process ("musescore") comes from?

It's a link created by the package, shouldn't change anything to this issue. I may have called mscore directly from the terminal for debugging purpose. Good observation though.

~$ ls -l /usr/bin/musescore
lrwxrwxrwx 1 root root 6 Oct 24 08:17 /usr/bin/musescore -> mscore

edit: just confirming that it happened in another machine with a fresh install, also a Debian system.

I've been experiencing similar crashes when saving after editing the staff properties to change the name of an instrument. After saving, sometimes it crashes and leaves the file, sometimes a 0-length file.

Since the material originated with a scan of a copyrighted choral work for my own use, I'd rather not post it here. I was experimenting with adding a simple orchestration. So maybe try starting from a score with significant content, adding a new instrument, save, then edit the staff properties of the new (or old) instruments, and save.

It is also possible that the XML from the scan is the problem here, it did require some significant cleanup. After starting from a new score with Piano + SATB, copy/pasting the scanned piano and voice notes from the scanned score into the new score, adding the same instruments, I don't get the crash anymore.

This on OS X 10.10.5 (Yosemite). Have seen similar crashes on Windows 8.1 working with scanned material. It has nothing to do with sync, I'm just editing local files. Dropbox is installed but the score is under Documents/MuseScore/Scores, not in the Dropbox directory.

Hope this helps, will post an isolated example if I can find one.

I can confirm that it happens more frequently here when editing staff properties, such as instrument names. It doesn't matter if I'm editing a huge orchestral score or a small SATB one.

I've got some output from strace and gdb (see below), hope that can give you some idea:

https://paste.debian.net/332678/

Also, I've disabled the auto-save option just to confirm that the segfauls are not related to it. And yes, it keeps crashing without it enabled.

I'll be in the IRC channel in case you need me to perform any further debug task.

@tiago this issue sounds similar like yours: #87241: Persistent bug when changing Instrument names - crashes and wipes savedfile

The affected song files are all located on my local HD inside my Mac Powerbook - not networked or in the Cloud.

My current work-around is to "Save As" both before and after changing Staff Properties.

Just a short note to say that it's also crashing in this nightly build: 201511111001+REVISION.421f366~ubuntu15.10.1

Under the following duplicate issue, there are some recently entered comments that might be helpful:
https://musescore.org/en/node/87241

An indice maybe.
To reproduce a crash constantly with the file attached in comment #16. This one: mscore_issue.mscz

So:

1) Load the file above
2) Generate parts (new all -> Ok)
3) View "Cors 1,3" part
4) Select the measures like this:
5) Intention: delete this selection. But, important: instead doing Ctrl + Del, as usual, you must associate the Shift key
So: do Ctrl + Shift + Del

Result: crash

EDIT:

Other related indice (or other form)

Repeat same steps as above: 1, 2, 3
4) Select this measure:

5) Ctrl + Shift + Del
Result: unexpected

6) Wait: the time for Auto Save (2 or 1mn depending your preference)
7) After one/two minutes: the layout reverts as excepted

Ok, I can reproduce a minimal crash from scratch. Presently, I don't know if the initial issue of this thread is completly or partially (more or less?) related to this.
So, I filled a new issue for this minimal crash.

I can reproduce the crash above. However, I think it's not related to the "Save leading to a 0byte mscz file" issue.

Please check the video I've made showing the Save issue:

https://owncloud.acaia.ca/public.php?service=files&t=8c82f4be104d261beb…

In the first crashes MuseScore is able to recover the file. In the last one MuseScore doesn't recover it. The related mscz file is attached in case you want to reproduce it yourself.

"I think it's not related to the "Save leading to a 0byte mscz file" issue."
I have not tried your last file, but I can give you right easily.
I mentioned an indice, not more.
Sometimes, you are looking for something, and you come across something else!

Thanks @cadiz1! Please don't get me wrong, it's appreciated that you've taken the time to test and nice to see you found another crash situation to report :)

I have posted some autosaved files from my hidden Library/Musescore folder which may be helpful in resolving this bug.
I posted them on a duplicate issue:
https://musescore.org/en/node/87241 (mine)
I have also raised a question about the timing of Auto-saved files.
-Tom

Another info which can be helpful: I've switched back to 2.0.1 (b25f81d) and after 2 hours of work it didn't crash. I've been working on the same score that crashes a lot with 2.0.2. So we may assume that it's something specific to MuseScore >= 2.0.2 (nightly builds also crash here).

The specific bug I have mentioned I think is the root cause of this was an issue in 2.0.1 as well. It is triggered any time a save happens with an instrument name selected while in continuous view, and this is also the case in 2.0.1 and in 2.0. So far I still strongly suspect that what you are seeing here is the same basic issue.

For what it's worth, I have been monitoring the contents of the MuseScore folder in ~/Library/ (on my Mac) and I don't see files being auto-saved there every two minutes like my Preferences say should be happening.
Perhaps this is why "Restore Previous Session" doesn't work after a crash?
-Tom

Files will only be auto-saved if there have been changes you havent saved yourself. So, open a score, save it, now make a change, wait two minutes, and the auto-save score should appear. Wait as long as you like and it will not update because there is nothing to update. But make another change to the score, and two minutes later, that auto-saved version will update.

"Files will only be auto-saved if there have been changes you havent saved yourself"

Hmm! Just, checked, and my Musescore is saving every two minutes no matter if changes have been made or not.

Sti2nd and Marc,
The auto-save feature does indeed work as Marc has explained. The auto-saved file overwrites itself with each new auto-save.

But this presents the user with a "catch-22" type problem.
The bug wipes the Saved file, and Auto-Saves is suspended while manual Saves are being done.
The result when the bug strikes is that the conscientious user has no Saved file to restore, and due to their frequent manual saves, no recent Auto-Save file to recover, either.

1) Could Auto-Save be changed or have a check-box added so that it saves every two minutes even if the user has saved manually? Since Auto-Save files overwrite themselves, this would not add any clutter to the MuseScore folder.
2) Until (1) is done, should users be advised NOT to manually save files while they work, so as to have a recoverable file that is no more than 2 minutes old, in event their main file gets wiped by this bug?

-Tom

@tomfeledy, I'd rather warn people to not save their work having the instrument name selected while this issue is not fixed.

@Marc, that's it, instrument name selected leads to crash during save. However, I can't find that problem in MuseScore 2.0.1, so far.

Any news on this? I've just lost another 4h of work, can't believe! :( Saving each 5min and got a version from 4h ago in my .local/share/data/MuseScore/MuseScore2/ oh my...

Sorry to hear that! Werner did make a change that should prevent zero-length files on write - writing to a temp file then only replacing the original after the operation completes. So this shouldn't be an issue any more in current development builds.

Assuming you aren't ready to start using nightly builds for regular work, I guess if you yourself messing with instrument names and selection often, maybe get in the habit for now of using Save As to save snapshots.

That's a great news, thanks, hope you release a new version soon with this fix! I've been saving regularly with 'save as a copy' feature but last night I just forgot to do so and got bad luck. Anyways, I'm glad I've got some background in forensics and was able to recover my work by hard-carving my disk.

That's great, glad to hear you were able to recover!

I have not had any further crashes by simply avoiding the use of "Continuous View."
Too bad, because I find Continuous view more efficient for processing scores.
I hope we get a release soon that allows us to resume using Continuous View without risk of losing our work subject to this bug.