Crash press ‘space bar’ in entering fingering mode on TAB stave when note is tied beyond barline

• Jul 18, 2019 - 05:14
Reported version
3.2
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
fixed
Regression
No
Workaround
No
Project

OS: macOS High Sierra (10.13)
Arch.: x86_64, MuseScore version (64-bit): 3.2.3.22971
revision: d2d863f

1.Create score, Guitar + Tablature
2.Check ‘Show Fingering in Tablature via
Right clicking Tab stave -> Staff/Part Properties ->Advanced Style Properties
3.Click a beginning tied note which is tied beyond barline on Tab Stave
4.Enter fingering mode on that note ( Menu bar ; add->Text->Fingering)
5.Press ‘Enter”

Crash

Seems this happens only on Tab stave.

Attachment Size
example.mscz 3.48 KB

Comments

Frequency Many Once
Severity S3 - Major S2 - Critical

Confirmed. Indeed, only in TAB staff, and only is the option "Show back-tied fret marks" (Advanced Style Properties) is unticked.
Test file like that: hidden tied fret marks.mscz
Works as expected if tied fret marks are visible: visible tied fret marks.mscz

NB: step#5 = Press "Space bar"

My first guess: Maybe a side effect due to a change in this PR/commit? https://github.com/musescore/MuseScore/pull/5105
But I don't really know, I haven't check.

Title Crash press ‘enter’ in entering fingering mode on TAB stave when note is tied beyond barline Crash press ‘space bar’ in entering fingering mode on TAB stave when note is tied beyond barline
Type Development Functional
Priority P0 - Critical

Yes, it seems that when are trying to find the next element, we see the tie exists, but when we try to access it we find it was ever laid out. There's an easy fix for the crash, but as is sometimes the case, it's not completely clear to me if the underlying cause (the existence of a tie that hasn't been laid out) is problematic in other ways. So far I guess no other problems were reported with that, so that's good.

FYI, even though Space in "fingering mode" skips everything but notes, internally it is using Alt+right "next element" common and skipping anything that isn't a note.

Status PR created fixed

Fixed in branch master, commit 2ae98b962c

_fix #292312: crash on next element with hidden tie

Null pointer dereference due to ties never being laid out on tablature.
This happens during fingering input but internally that is using the accessibility functions,
same code as Alt+left/right, so the same crash exists there.
Fix is simple check for null.
A later commit in this PR refactors the check to a function tieValid()._