Persistent bug when changing Instrument names - crashes and wipes savedfile

• Nov 14, 2015 - 19:37
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S2 - Critical
Status
closed
Regression
No
Workaround
No
Project
MuseScore
Tags
2.0.3

About every tenth time I change an instrument name, MuseScore crashes. Most of the time I can hit Recover and get back to my working file. But occasionally, like just now, it wipes my saved file to zero-K and MuseScore can no longer open it. This represents the loss of hours of work, which now must be redone.
I have reported this before.

GIT commit: f51dc11

Attachment Size
Lights of Hanukkah Kern c.mscz 0 bytes

Comments

• Nov 14, 2015 - 20:31

Here are a bunch files and crash reports from my Mac.
I have tried to link the crash reports with their associated score files.

The crash either occurs consistently, when I have the Staff Properties window open and I am either editing the Part Properties fields, or when I hit "Save" or "Save As,"after I've finished editing these fields and closed the Staff Properties window.

Attachment Size
Lights of Hanukkah Kern d.mscz 0 bytes
Crash d2.txt 77.39 KB
Lights of Hanukkah Kern e.mscz 36.87 KB
Lights of Hanukkah Kern f.mscz 36.97 KB
Crash f-g.txt 76.31 KB
Lights of Hanukkah Kern i.mscz 37.03 KB
Lights of Hanukkah Kern j.mscz 0 bytes
Crash i-j.txt 75.38 KB

Reply

• Nov 15, 2015 - 01:51

But note that a crash should never result in loss of more than two minbutes work, because MsueScore auto-saves your score every two minutes. After a crash. MuseScore should ask you if you wish to recover that version. Even if you accidentally decline, the auto-save file is left on your system so you can open it manually later.

Reply

• Nov 15, 2015 - 02:04

Also, for the record, the "Assigned" field in the issue tracker is meant to identify the person who will fix a bug, not the person who reported it.

BTW, the crash in the first log makes it look likely this is related to #84351: Crash when saving with instrument name selected and continuous view, #85046: Crash when adding/removing an instrument in Continuous view after autosave, or possibly #63226: Crash on autosave after deleting staff from instrument in score with linked parts. The first in particular. My guess is you are accessing Staff Properties by selecting and then right clicking an instrument name first, while in Continuous view, and thus you are triggering the exact conditions for that bug. The workaround would be to not select instrument names but instead invoke Staff Properties by right clicking the staff. Tough to remember if you're already in the habit of using the isntrument name to access the dialog, but perhaps worth keeping in mind.

Reply

• Nov 15, 2015 - 04:35

Marc,
Thank you for your comments. I am new to this forum so I appreciate the feedback on its use.

I was not accessing Staff Properties by selecting and then right clicking an instrument name first, I was right-clicking on the staff to get to the Properties window. I was in Continuous view. Do we know if switching to Page view avoids this bug?

Reply

• Nov 15, 2015 - 04:47

When MuseScore crashed, I got the Mac window asking if I wanted to restart MuseScore. So I clicked to restart MuseScore.
When MuseScore started up, it asked if I wanted to restore the previous session . I said yes, and then got an error because my saved file which restore was trying to open had been wiped to zero K.
I tried to find an auto-save file, but contrary to what is said on this Help page:
https://musescore.org/en/node/52116
this folder path does not exist on my Mac running OS 10.10 (Yosemite):
Mac OS X: ~/Library/Application Support/MuseScore/MuseScore2/

1) Where are the auto-save files to be found?
2) Are there any settings for auto-save in the MuseScore software? Maybe I have to turn something on to get auto-save?
3) I have seen files with lots of underscores saved in a folder in Documents/MuseScore2/Scores. I looked in this folder for an auto-save file, but only found one with a time-stamp several hours prior to the crash I was reporting.

Reply

• Nov 15, 2015 - 05:18

Well, we know that the specific crash in the issue I mentioned only happens in Continuous View, and your crash log seems similar.

As for auto save files, I don't know much about Mac; I guess mabe the version of the OS you have might put that folder somewhere else.

You can set the auto-save interval in Edit / Preferences.

Reply

• Nov 15, 2015 - 05:31

The folder is hidden, but it does exist. In Finder, hit [Shift]+[Cmd]+[G] and copy and paste the full path (including the "~") into the "Go to Folder" dialog, and it will take you straight there.

Reply

• Nov 15, 2015 - 07:20

Marc,
On my Mac, the "Preferences" is under the Apple menu.
It allows me to control the time between autosaves, but not the folder they get saved to.
The next reply by ZackTheCardShark explains where to find the autosave folder on a Mac. (Clue: it is a Hidden folder).
My question is: why is this folder hidden, and why can't the user specify its location?
-Tom

Reply

• Nov 15, 2015 - 07:34

Zack,
I tried what you suggested, but I got a "folder not found" error.

Unless I am doing something wrong, it seems the MuseScore folder containing auto-saved files does not exist on my Mac under Library/Application Support.
By comparison, there are about 30 other folders in Application Support, including for example, Finale's MakeMusic folder, and none of them are hidden.
Why should MuseScore's folder be hidden?

Where else could MakeMusic be putting auto-saved files on a Mac?
-Tom

Reply

• Nov 15, 2015 - 14:40

This may be confusing, but /Library/Application Support is not the relevant folder. You need to get to ~/Library/Application Support.

~/Library is the folder that's hidden; it's in your Home folder, and it's hidden because it contains system files that should not be deleted. Again, it's important to include the "~" at the beginning of the path, so as not to be confused by a different, similarly named, folder.

Reply

• Nov 15, 2015 - 16:32

Thanks, Zack.
You have cleared it up for me.
I overlooked the "~" at the beginning of the string.
I have edited the following Help page that describes this to make it clear to others like me who may be confused by the presence of a non-hidden Application Support folder that contains folders for several apps, but not MuseScore.
https://musescore.org/en/node/52116
-Tom

Reply

• Nov 15, 2015 - 21:14

Zack,
Although I was able to find the MuseScore backup files as you suggested, the files I found were not helpful in recovering the several hours of work done prior to my crash.
First of all, I found only 4 files auto-saved near 1150, the time of my crash.
The files I found were timed 1029, 1153, 1203 and 1210 hrs (see attached.)
None of them contained the work I had done on the file from 1000-1200 hrs.
The file timed 1203 was zero-K bytes in size and un-openable.

It is not clear to me why the backup files in the hidden Library/MuseScore folder are not spaced at 2 minute intervals, as is set in the Auto-Save Preferences.

Attachment Size
scAJ1015.mscz 36.91 KB
sccY2614.mscz 36.82 KB
scjF2926.mscz 36.92 KB
scKe2827.mscz 0 bytes

Reply

• Nov 16, 2015 - 02:38

No auto-save happens if you do not make any changes that require saving. And only the most recent version is normally kept as far as I know. So you should never expect to see two versions of the same file saved two minutes apart.

Reply

• Feb 19, 2016 - 02:19

#84351: Crash when saving with instrument name selected and continuous view is fixed in the nightly builds that will become 2.0.3, so if you install a Nightly build (see Downloads link in menu at right of this page, then scroll down), you should be able to verify if it works for you. Also we've changed the file saving code in the nightly builds to not replace the original file until the save is complete, so even if a crash happens mid-save for some other reason, it should never be the case that anything is ever lost.

So there are still crashes that could happen, but not that specific one (save with instrument name selected in continuous view), and when crashes do happen, they no longer are in danger of destroying work even if they happen mid-save. The question is, are there aspects of this current issue that are not addressed by those two facts? If so, what specifically?

Reply

• Feb 28, 2018 - 13:49

I can confirm this issue on MuseScore version 2.1.0 revision 871c8ce running Ubuntu 17.10 with a 4.13.0-36-generic kernel.

It has happened a few times but it happened yesterday night. I had done a lot of changing instrument names and sounds, and done a lot of switching between view modes.

Since this had happen a lot of times before so I intentionally saved and exited MuseScore properly to try to prevent this.

But... this morning when i opened MuseScore, the file size was 0-bytes of despair and sadness.
This coupled with the fact that the most recent backup happened ~3h before i stopped working with the file makes me "a tad bit annoyed".

Noteworthy might be that the last modification date for the file was this morning, so it is possible that the file was wiped when i started MuseScore and not when I saved and exited. Which might be noteworthy.

-rw-r--r-- 1 grandmother thegranmdother   18067 feb 27 22:44 .12.mscz,
-rw-r--r-- 1 grandmother thegranmdother       0 feb 28 13:35 12.mscz

This might sound a bit rude but why this bug has persisted for over two years perplexes me.
I love MuseScore and I use it almost everyday and it has really helped me grow as a "musician".
But seriously, complete loss of data might be the most annoying bug possible after having your computer catch fire and burning you alive.

I'm not angry, I'm disappointed.

Also, AFAIK muse score only backs the file up if no manual save has occurred within the defined time period?
A feature to have it always backup the file regularly regardless of whether or not one saved it might be neat as a workaround for this.

Sorry for being a bit hostile, but seriously....

Reply

• Nov 30, 2018 - 08:38

I created a pull request concerning this issue: https://github.com/musescore/MuseScore/pull/4268
First, in case of such failures the resulting file will not be empty anymore and it would be possible to restore data from it using external archive programs.
Second, I fixed a particular case of this issue that I was able to reproduce which happens on saving a file when a bracket was selected in continuous view.
I don't believe it to be a complete fix for this issue so I don't change a status for it but this PR can make the situation with it slightly better.

Reply

• Dec 1, 2018 - 17:26
Status active ⇒ PR created

I updated the mentioned PR (https://github.com/musescore/MuseScore/pull/4268) to cover the whole issue of invalid pointers presence in selection. As this topic seems to be mostly about this kind of save failures (at least the backtrace files posted in the beginning of this thread are exactly about this case) maybe this issue could be considered fixed if this PR gets merged.

Reply

• Dec 3, 2018 - 15:00

Fixed in branch master, commit 79d5bed7d4

Merge pull request #4268 from dmitrio95/87241-corrupted-files-and-selection

fix #87241, fix #279064: Remove invalid pointers to elements from selection and avoid complete data loss in case of crash on saving .mscz file

Reply