Dragging key signature from custom palette to score leads to crash

• Mar 14, 2019 - 02:37
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore
Tags
easy

Create a custom workspace that includes the Atonal key signature.
Drag the Atonal key signature to the score

Result - crash with no warning.

Note: double clicking to add key signature does not cause a crash, but cannot be used to set key signature in a single staff as is the most common use. Adding this from the advanced palette does not cause a crash, which can be applied to a single staff.

Comments

• Mar 14, 2019 - 06:01
Title Dragging atonal key signature from custom palette to score leads to crash ⇒ Dragging key signature from custom palette to score leads to crash

Took me a minute to figure out how to reproduce. It's doesn't happen with the key signature already on the palette (custom or not), only a key signature added to the palette from the master palette. So you'd have to have started with the basic palette and then added the atonal keysig, I guess. Although the bug isn't just with the atonal key sig - it actually applies to any of the predefined keysigs on the master palette. Drag one to a custom palette then to your score, crash.

BTW, you can add a keysig to a single staff via double-click, just hold Ctrl same as you would while dragging.

Cause of crash appears to be that the keysig is set to track 0 during the drag, rather than -1 as it should be since it does not yet belong to a staff. This is actually a problem for custom keysigs too but doesn't lead to a crash because we don't try to do anything with the staff info for a custom keysig, whereas for normal keysigs (including atonal ones) we look at the staff to know the clef so we can figure out how to lay out the keysig.

Looking at the palette file itself, I see the track 0 tag right there, so the palette itself is the problem. That is, th bug is more about the creation of the palette than the dragging from it. But we should try to fix it even for already-created palettes.

Reply

• Mar 14, 2019 - 06:26

Actually, track 0 tags are common throughout the palette but they don't cause problems during drag & drop, I think because we usually check parent() first to see if the element is actually added to the score yet. So probably that's the fix here too.

Reply

• Apr 3, 2019 - 11:56

Hi @Marc Sabatella , I'm trying to solve this problem. I have found the lines you mentioned but still don't understand why it crashes. This keysig to be displayed is not yet added to the score so it doesn't have a parent, and thus a segmentation fault is received since we try to call a method of a null object. Then why doesn't it crash when it comes to normal keysigs? They don't have a parent before being added to a score either.

Thank you.

Reply

• Apr 3, 2019 - 14:46

Normal keysigs have a track of -1, not 0. That means staff() will return null, and thus the lines that are causing the crash never get executed because they are in an "if (staff())" clause. If you look at other layout functions, you often see something like "if (!parent()) return;" early on in the function. WHat I'm suggesting is that something like this added here too. So keysigs with no parent can skip all the fancy processing below.

Reply

• Apr 4, 2019 - 05:14

Then why do we set the track of keysigs and other elements to 0 when dropped at a palette? And I just found another bug related to custom keysigs....

Reply

• Apr 4, 2019 - 06:06

Not sure what you are asking. As I said, most elements are actually set to track -1, but elements the user adds himself are set to 0 and they probably shouldn't be.

Reply

• Apr 4, 2019 - 07:34

I just want to know if there's any reason that the author decided to set elements added by users to track 0. If they shouldn't be track 0, I'll fix this as well by setting them to -1 (and also checking for parents).

Yes I just found that the issue is reported. Thank you!

Reply