Crash when loading palette with small width/height grid

• Jan 7, 2017 - 16:37
Reported version
2.1
Type
Functional
Severity
S2 - Critical
Status
closed
Project

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

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

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.

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. :-)

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

Attachment Size
Robbie_2.workspace 3.39 KB

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.

Attachment Size
MuseScore-Palettes.png 73.37 KB

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).

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.

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. :-(

Status (old) active needs info

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.

Status (old) fixed closed

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.