Version 3.2.3 crashes when opening if the 3.3. RC is installed
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
Ouch.
And hard if not even impossible to fix: next version will be the final, and that will overwrite then 3.2.3 and so that bug is gone.
"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?
I guess that'd be the only sensible thing to to
But let @dmitrio95 and/or @Anatoly-os decide...
In reply to "next version will be the… by cadiz1
I'm concerned about this bug but I agree
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
In reply to "But that crash can be also… by cadiz1
On my PC, Windows 10 1903 defines the .workspace extension as an Adobe file and I think this is a problem but I don't know how to solve it.
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 Windows lets you define the… 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:
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.
In reply to Probably musescore.org doesn… by dmitrio95
dmitrio95
Here is: Papibois2.zip
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 Windows certainly allows you… 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.
See https://github.com/musescore/MuseScore/pull/5369.
Well, that PR doesn't prevent the crash in 3.2.x... Unless we do a 3.2.4, which isn't planned.
In reply to Well, that PR doesn't… by Jojo-Schmitz
Isn't the crash happening because of 3.3 RC?
Yes, that is exactly why I didn't change the status here.
> 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.
In reply to > Isn't the crash happening… by dmitrio95
So what does it take to close this particular issue if your fix cannot do it?
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.
True, so the status should remain "active" all the time or changed to "won't fix" or "closed"?
"won't fix" is probably the most appropriate status