Version 3.2.3 crashes when opening if the 3.3. RC is installed

• Oct 4, 2019 - 11:07
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
won't fix
Regression
No
Workaround
No
Project

Steps:

1) Install version 3.3 RC.
2) Open the 3.2.3 (double-click icon, or right-click/Open)
Result: crash

Seen twice on the French forum, here: https://musescore.org/fr/node/295210#comment-948886

(personally, I can't reproduce, but since I always restore the default settings when I change versions - the palettes are concerned so - maybe that's the reason, I don't know)


Comments

"next version will be the final, and that will overwrite then 3.2.3 and so that bug is gone."

I had thought about that indeed. So can we consider this issue as "won't fix" status and close it?
And probably due to the huge change of the palettes I guess?

The file format for new palettes is designed to be fully compatible with 3.2.3. Some features may be missing of course, but otherwise 3.2.3 version should open palettes constructed in 3.3 version correctly. Maybe if we could get a .workspace file that (possibly) causes a crash this issue could be investigated better. But that crash can be also not related to palettes.

@Papibois tells me that this file appears only in PDF format! I don't know how that's possible: https://musescore.org/fr/node/295210#comment-948935

See translation below, and picture (in comment link above)
"Here these workspace files appear as PDF files although Acrobat Reader cannot open them.
And I can't attach them to the Issue Tracker.
This may explain the bug.
However MS3.3 RC displays my different workspaces correctly"

For my part, I receive as expected this file: https://musescore.org/fr/node/295210#comment-948923

Probably musescore.org doesn't allow .workspace files to be attached here, please rename that file to .zip (or copy it and rename that copy) and attach it here. After posting it you can rename it to .workspace back.

Windows lets you define the file association for ".workspace" however you like. I guess Adobe must have claimed it by default and MuseScore does not, probably because we don't allow opening them directly (or do we?). So I don't think there is a problem that Windows reports the file as being an Adobe file - as far as Windows knows, this is true.

In reply to by Marc Sabatella

Not really. Windows does not allow me to change this file definition; it just sends me to the Windows store to find a program that can open it and Window Store does not offer any.
So there is probably a modification to be made in the Registry but I don't really like to venture there.
I tried another trick to prevent my wokspaces from being seen as Adobe files and I succeeded:
Capture5.JPG
Capture6.JPG
To do this I renamed a text document to.exe and indicated this "fake" program as the default to open my workspace files. Then I deleted this.exe so that windows no longer indicates any program to open them. What I wanted.
I then uninstalled MS 3.3 RC, performed a CCleaner, restarted and reinstalled the RC. The workspace files have remained normal but MS 3.2.3 remains inaccessible:).
So that's not the problem.

Windows certainly allows you to change file associations, in several different ways. One is to simply right-click a file with that extension, then "Open With" - select the app under "More apps" (ignore the offer to go to the store) and check the box to always use it). You can also type "File Associations" into the Windows search box and choose the match offered, which brings up the window to choose default apps by file type, all in a big list.

But it's irrelevant here, I don't think it would help to have the file type associated with MuseScore since as far as I know MuseScore doens't actually open these files directly. So, there is simply no problem with the fact that Windows think it's an Adobe file. All that means is if you double-click it in Windows Explorer, it will try to open in an Adobe program, but that in no way should be a problem, because you shouldn't be double-clicking those files, or indeed looking at them normally.

In reply to by Marc Sabatella

Thank you Marc, I know how to change a file association but in this case there must not be any. The icon of the file must remain white, i.e. it must not be associated with any program to open it.
But since in the end, like you, I don't think that's the source of the problem that blocks version 3.2.3., I'll look for something else.

So, here a culprit. Chant.7z

Steps to reproduce the crash (I can now with this file)

1) Uncompress and add this workspace "Chant" (created with 3.3 RC) in the 3.3 RC - workspaces folder.
2) Open 3.3 RC -> Switch to this workspace, nothing more.
3) Exit the program
4) Open now the 3.2.3

Result: crash

EDIT: to be more precise, the workspace file "Chant" must be added via the path: AppData/Local/MuseScore/MuseScore3 (and not MuseScoreDeveloppement)/workspaces.
This done, the crash by opening the 3.2.3 is avoided if this workspace is removed/or simply not currently displayed in the 3.3 R.C.

So, the issue happens when a workspace contains preferences from 3.3 version so not storing them works around this issue (View→Workspaces→Edit→untick "GUI Preferences").
Also I attach the corrected workspace (with removed ui/canvas/foreground/useColorInPalettes preference) which will open in 3.2.3 without losing other settings, thought an attempt to open it with 3.3 will lead to this problem again.

Here is also a patch that should prevent similar issues from happening in future versions of MuseScore: https://github.com/musescore/MuseScore/pull/5369.

However I am not really sure what should be done regarding this issue between 3.2.3 and 3.3 versions. The ideal solution would be to add that fix to 3.2 branch as well but since we were not planning any updates for 3.2 series this may happen to be not possible.

Attachment Size
Chant_corrected.workspace.7z 9.08 KB

> Isn't the crash happening because of 3.3 RC?
It happens mainly because of incorrect handling of unknown settings in the code that is involved in reading workspaces, and 3.3 version just adds one more preference that may appear to be written to a workspace file.

If we are not planning to do 3.2.4 release then the only fix would be to avoid adding new preferences (at least those related to GUI appearance) to MuseScore at all, in any future 3.X version. This doesn't seem to be a good solution.