Crash on Ctrl+Shift+drag of score element on Linux (under ChromeOS)
Reported version
3.3
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
Apparently this works on at least some Linux systems, not sure if it's truly about running in a container under ChromeOS as I am or if it would be possible to reproduce in a similar Linux environment (a fairly minimal Debian stretch) outside that world. In any case:
1) default score
2) Ctrl+Shift+drag the title (as if you were going to add it to a custom palette)
Result: crash. A really hard crash, at that - when run under gdb in QtCreator, it takes the whole debug environment down with it.
Apparently something doesn't like the null pixmap we are attaching to the drag cursor. Fix forthcoming.
Fix version
3.3.3
Comments
https://github.com/musescore/MuseScore/pull/5476
Fixed in branch master, commit 484cd7e81e
_fix #297152: crash on Ctrl+Shift+drag on Linux (under ChromeOS)
Resolves: https://musescore.org/en/node/297152
This might be unique to Linux apps on ChromeOS,
or it might apply to other Debian "stretch systems",
but apparently passing in a null or 1x1 pixmap to a QDrag
causes it to crash on exec().
This PR fixes the problem by making the pixmap 2x2.
It also allocates it statically to be sure there is no issue
with it coming off the stack.
I also replaced the deprecated QDrag::start() call with QDrag::exec(),
which we already do when dragging from the palette.
This is recommended as per Qt guidelines._
Fixed in branch master, commit 75c7759276
_Merge pull request #5476 from MarcSabatella/297152-clone-pixmap-crash
fix #297152: crash on Ctrl+Shift+drag on Linux (under ChromeOS)_
Automatically closed -- issue fixed for 2 weeks with no activity.