Changing instruments from a tablature crashes the program

• Feb 22, 2020 - 18:51
Reported version
P1 - High
S2 - Critical

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: 148e43f

I know that this is not supported, and that the opposite use case is probably more tempting (ex: wanting to get a guitar tablature from a piano score, it's not uncommon to read it on the forums).

Nevertheless, I suppose that this one, e.g. from a tablature retrieved somewhere, for wanting to obtain a violin score, is not completely to be ruled out.

With 2.3.2, it failed, of course, with this display of red squares and question marks - image below (and by undoing, the situation returned to the way it was before).

With 3.4.2, the program doesn't like it at all and dies immediately. That should not happen.

So, steps:

1) Open this test file: TAB.mscz
(excerpt of Tablature template with a few notes):
2) Right-click TAB staff-> Staff properties -> Change instrument -> Let say, violin (or flute, or piano) -> Ok

Result: the programm shuts down

  • result with the 2.3.2

    red squares.jpg


Reproducibility Always Once
Status active needs info

I cannot reproduce the crash using the latest version on the master branch.
(OS: Ubuntu 18.04.3 LTS, Arch.: x86_64, MuseScore version (64-bit): 3.5.0, revision: 3543170)

I cannot reproduce under Linux, but I can under Windows.
Under Linux, with AddressSanitizer and UndefinedBehaviorSanitizer, I see the runtime message:
libmscore/stringdata.cpp:154:26: runtime error: variable length array bound evaluates to non-positive value 0

Under Windows, with AddressSanitizer (via Clang), the backtrace of the crash is the following:
==1928==ERROR: AddressSanitizer: access-violation on unknown address 0xffffffffffffffff (pc 0x000145094ddd bp 0x00000013d240 sp 0x00000013cf80 T0)
==1928==The signal is caused by a READ memory access.
#0 0x145094ddc in Ms::StringData::fretChords(class Ms::Chord *)const C:\Git_packages\MuseScore\libmscore\stringdata.cpp:248
#1 0x142658851 in Ms::Chord::cmdUpdateNotes(class Ms::AccidentalState *) C:\Git_packages\MuseScore\libmscore\chord.cpp:1723
#2 0x142f0a84a in Ms::Score::getNextMeasure(struct Ms::LayoutContext &) C:\Git_packages\MuseScore\libmscore\layout.cpp:2654
#3 0x142f5cd78 in Ms::Score::doLayoutRange(class Ms::Fraction const &,class Ms::Fraction const &) C:\Git_packages\MuseScore\libmscore\layout.cpp:4496
#4 0x1419619ca in Ms::Score::update(bool) C:\Git_packages\MuseScore\libmscore\cmd.cpp:302
#5 0x14026b8ea in Ms::Score::update(void) C:\Git_packages\MuseScore\libmscore\score.h:737
#6 0x1438b8427 in Ms::EditStaff::apply(void) C:\Git_packages\MuseScore\mscore\editstaff.cpp:404
#7 0x1438b2c55 in Ms::EditStaff::bboxClicked(class QAbstractButton *) C:\Git_packages\MuseScore\mscore\editstaff.cpp:287

The strings() function returns 0 after the instrument change, so I don't think the bUsed vector is properly created here:…
(even in Linux case, here:… )

Status active PR created

That might prevent the crash, but we can do better. The problem, of course, is that the user has selected an instrument that is incompatible with the staff type, but the staff type is not updated to be compatible with the instrument. StringData::fretChords() is only called if the staff type is part of the TAB staff group, so choosing an appropriate staff type will effectively solve this issue. And indeed, if the staff type is changed to "Standard" (via the instruments dialog) before choosing a different instrument in the Edit Staff dialog, the operation succeeds without a problem. See for my solution.

Status PR created fixed

Fixed in branch master, commit f215d00c98

_fix #301488: Changing instruments from a tablature crashes the program


When the user chooses a different instrument in the "Edit Staff" dialog box, it is important to make sure that the new instrument is not incompatible with the staff type. This is accomplished by setting the staff type to the preset staff type for the chosen instrument._

Fix version