Potential nullptr dereference in PianoView::updateNotes()
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
- I opened a .mscz generated by the online PDF importer (from a guitar score+tab) and started figuring out how to get rid of the empty 2nd stave that could (should) have been the tabulature representation.
- I opened the piano roll editor during this quest (and closed it without doing anything). I don't remember exactly what I did and in what order, but after finally getting rid of that stave
- I tried to adjust the page settings. Changing the paper size went OK but while adjusting the margins mscore crashed and KDE's DrKonqi popped up.
The crash happened in PianoView::updateNotes(), trying to get the staff ID from a NULL _staff pointer variable. I suppose that variable should have pointed to the stave I deleted. I added a local patch to my build (int staffIdx = _staff ? _staff->idx() : -1;
) but haven't taken the time to check if that doesn't just delay the crash (IOW, if more locations need to be patched). I guess the real question is why a PianoView instance would be updated if it has been closed.
Fix version
3.5.2
Comments
There is
So with the
_staff
beingNULL
, it should exit early alreadyEdit: I see, it does this in
PianoLevels::updateNotes()
(and inNoteTweakerDialog::updateNotes()
too), but not inPianoView::updateNotes()
. I guess it better should...See https://github.com/musescore/MuseScore/pull/6667
Not in the 3.x branch there isn't (and I find my fix more elegant ).
The underlying question remains: why would these functions be called if the corresponding view/widget isn't being shown, esp. if they're also called when the view/widget is unhidden?
3.x branch looks the same as master in this respect.
In reply to 3.x branch looks the same as… by Jojo-Schmitz
From #3.5.0-207-gcc225b645 on github:musescore/MuseScore :
(the only changed line is my fix)
Yes, that is one way to fix it, but I'd rather copy what other 2 very similar methods use, for consistency.
I'm not quite sure though how this new and the existing 'early exit' play along with that
scene()->blockSignals(true);
. But at least my change (nor your's) change this.Fixed in branch 3.x, commit 9c41e34e85
_Fix #311661: Fix potential crash in
PianoView::updateNotes()
and in the same way as it is done in
PianoLevels::updateNotes()
andNoteTweakerDialog::updateNotes()
_Fixed in branch master, commit 51b720e3a1
_Fix #311661: Fix potential crash in
PianoView::updateNotes()
and in the same way as it is done in PianoLevels::updateNotes()and
NoteTweakerDialog::updateNotes()_
Automatically closed -- issue fixed for 2 weeks with no activity.