Crash when loading palette with small width/height grid
MuseScore 2.0.3 no longer opens for me and crashes reproducibly on startup instead.
I'm attaching a crash log.
Attachment | Size |
---|---|
MuseScore-CrashOnStartup.txt | 54.77 KB |
MuseScore 2.0.3 no longer opens for me and crashes reproducibly on startup instead.
I'm attaching a crash log.
Attachment | Size |
---|---|
MuseScore-CrashOnStartup.txt | 54.77 KB |
Comments
Actually 2.0.3.1 on a Mac...
Try https://musescore.org/en/handbook/revert-factory-settings#instructions-…
2.0.3.1 on a Mac is correct, yes.
I'm confident reverting to factory settings will get rid of the crash, especially since the stack trace seems to mention reading of the preferences. However, I'm hesitant to delete all my settings, I'd rather not lose them unless absolutely necessary…
Well, I'm pretty sure there's no other way. Unless you want to try hand editing your preferences files until the crsh no longer happens
Okay. I was hoping for a fix for the crash.
Well, a) we'd need to be able to reproduce the crash and b) it surely won't get fixed for/in 2.0.3.1, but maybe for 2.1, so you'd have to wait until that gets released.
Best bet it that something is wrong about the last score and MuseScore has been set to start with the scores from the last session. If so, you might be able to get the crash again by just loading that score (after a factory reset) and then attach that score here for diagnosis
Understood. :-)
I think that might be it. Do you happen to know which preference key I could modify to prevent MuseScore from opening the potentially defective score at startup? I've looked through all the ones in "org.musescore.MuseScore2.plist" but nothing seemed fitting.
check the MuseScore2.ini file? in the [General] section look for score-0
There is a problem with a custom palette. How many do you have? can you attach them?
Deleting score-0 did not help but I guess that shouldn't surprise when a palette's the culprit.
I think I have one custom palette. I have uploaded my workspace here: http://jmp.sh/mM4UWvA Coincidentally, I recently experienced a problem where the palette items were scaled wrongly which made them very hard to make out.
Thanks for investigating, Jojo and lasconic. :-)
Why not attach it here?
Removing the custom workspace from the "workspaces" directory allows me to launch MuseScore so lasconic's on point.
The problem is in the pixel width of the cell in the Beam Properties palette.
In the workspace file such width (
gridWidth
) is written as 0.842105, which is read as 0 and therefore it gives an arithmetic exception when computing column number (division by 0). Indeed, the width is actually an integer number.Attached a sanitized workspace where I simply modified 0.842105 to 1.842105. The cells of most of the palettes are extremely small, but these were the values (real values and not integers) written in the file.
I could not reproduce a real value instead of an integer value when saving a workspace. Was the workspace saved with a different version of Musescore?
Ciao,
ABL
Strange enough that gridWidth gets read using readDouble() rather than readInt(), And even without any compiler warning that a double won't fit into an int (without losing precision).
Closer look reveals that it seems to get cast: `
double readDouble() { return readElementText().toDouble(); }
Thanks a lot, ABL.
I don't recall which version of MuseScore I used to save the workspace, probably some 2.x version. I have tested MuseScore 3 nightlies since but the MuseScoreDevelopment directory would suggest it uses a different set of preferences. I also regularly switch between using MacBook Pro with a external display mirroring the computer's screen and without it. Maybe that (also) contributed to the odd gridwidth values…?
I'm attaching a screenshot of my Palettes sidebar. You can see that the palettes are pretty messed up, visually.
To avoid the crash we could introduce a safe guard
if (hgrid<=0)
hgrid=1;
here and here (using
vgrid
), but that would not cure the actual root cause which led to the messed-up workspace (that unfortunately we still do not know).Just ran into the crash again and was able to fix things by using ABL's sanitised workspace file again.
let's fix the crash by protecting the reading for now.
Fixed in branch 2.1, commit 01c4adef66
fix #154591: Crash when loading palette with small width/height grid
Fixed in branch master, commit 6c36ccc9d7
fix #154591: Crash when loading palette with small width/height grid
Thanks, lasconic.
In the meantime, I deleted my workspace, created a new one and haven't experienced the issue since. If I run into it again, I will try to come up with steps for reproduction.
Automatically closed -- issue fixed for 2 weeks with no activity.
I'm running into this issue again. Command line options like -D and -x are not helping.
I'd like to see if I can fix my workspace file but when I open it in a text editor there seems to be some encoding issue. Any hints?
I don't think -D and -x should be used at the same time?
That workspace file is compressed, similar to mscx and mxl files, you'd need to uncompress it first to then edit the files within, then update the compressed file with the updated file(s)
Ah, found out how to modify the workspace file: https://musescore.org/en/node/32586 But now I've editing the .xml file, zipped the folder and renamed it to .workspace my custom workspace shows up blank.
I've reverted to an older workspace file via Time Machine.
This is a pain in the backside. :-(
Also you don't get a crash, or do you? If you don't this is a different issue from the one at hand here.
Correct.
OK. And probably you made some mistake when editing that XML file. Maybe the -d option gives a hint in its debug output?
I may have. Thanks for the suggestion but but frustration has got the better of me and my patience is gone, I'm sorry. I will accept the issue and the fact I'll have to revert my workspace file every now and then.
For what it's worth, the issue of palette items being squished has been repeatedly reported since the release of MuseScore 2.0.3 (https://musescore.org/en/node/105146, https://musescore.org/en/node/109101, https://musescore.org/en/node/118481, https://musescore.org/en/node/124291, https://musescore.org/en/node/139186 to name a few). When this issue cropped up, regular users were frequently told to use command line options to work around the issue while no concerted effort was made to investigate the issue.
Reading further up in this issue (esp. #13 and #16) shows that the question how some apparently bogus values (gridWidth/gridHeight being smaller than 0.x and then interpreted as int, i.e. 0, then usid in some division leading to a Division by 0 error) made it into the workspace file, this is what needs to get investigated, and we'd need some clear step-by-step procedure to reproduce it.