Crash when changing drumset

• Feb 12, 2015 - 10:41
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

1. Open attached score (produced in 1.3).
2. Click bar (selecting it).
3. Right-click it.
4. 'Edit Drumset…'.
5. 'Load'.
6. Choose the attached drumset.
7. 'Open'.
8. 'OK'.

Result: Crash.

Note: See attached log.

Using MuseScore 2.0 Nightly Build 620c997 - Mac 10.7.5.

Attachment Size
Crash when changing drumset.mscz 1.79 KB
Crash when changing drumset.drm 3.18 KB
Crash when changing drumset [Log].txt 64.95 KB

Comments

• Feb 12, 2015 - 10:47

Possibly Qt? It could be here for informational purposes anyway.

It may not always be reproducible.

On the subject of drumset bugs:

Weeks ago, I encountered a similar crash (wasn't always reproducible). I don't think 'Edit Drumset' window went away when doing 'OK' (it does for the above bug). See the log .

There was another crash, I think after editing a drumset (and maybe accessing a Drumroll Editor) closing, or quitting a score - see the log .

Reply

• Feb 13, 2015 - 11:25

I *think* that this problem may arise from a much bigger and dramatic bug in Qt 5.4.0.
When I launch mscore under address sanitizer, I obtain a "global buffer overflow" error even at step 4. This is related to the Qt translation framework, which in this case is called at line 460 of libmscore/utils.cpp. This error also appears right at startup when I launch mscore after having enabled a translation. See attached address sanitizer log for the "Edit drumset" case.
This buffer overflow could also be the cause of bug #44771: [Mac] Preferences dialog not complete while in pt_BR locale.
I don't know if Qt 5.4.1 will solve the problem (I couldn't find pre-built 5.4.1 version for Linux).

Linux Mint 17.1, commit 4eda1f64e

Attachment Size
log_qtranslator_bug.txt 6.47 KB

Reply

• Feb 13, 2015 - 14:13

You could check, couldn't you? Just switch language to pr_BR, restart MuseScore and look at the prefs dialog? Seems to work OK for me, with an older 5.4.1 prerelease and under Windows.

Reply

• Feb 13, 2015 - 14:33

@Jojo-Schmitz: Not exactly. I could reproduce that bug only under Mac, but not under Linux.
A the moment I am re-compiling MuseScore with Qt 5.4.1 preview under Mac (it will take some time...).

Reply

• Mar 16, 2015 - 09:17

Finally I managed to (probably) reproduce the crash. There are a few additional steps:
1. Open the initial score of this report.
2. Click on the measure.
3. Enter note-edit mode (N).
4. (Optional) Exit note-edit mode.
5. Enter 'Edit Drumset' (if in note-entry mode, click on the button in the drumset toolbar; otherwise, right click the measure and select from the dropdown menu).
6. (Optional) 'Load'.
7. (Optional) Choose the drumset attached to the original report.
8. (Optional) 'Open'.
9. 'OK'.

I didn't get a crash, but running under Address Sanitizer shows that we are accessing a deleted variable. Linux Mint 17.1, commit d0e6b728ae
Attached the log.
If I understood correctly what is happening, when the drumset is set, the old drumset is deleted, but the reference to the drumset inside the drumtool is not updated, so when this drumtool is updated, it still points to the old (deleted) drumset. We need the drumtool to be initialized to be able to see the bug, that's why the initial "enter note-edit mode" instructions.

Attachment Size
drumset_log.txt 8.13 KB

Reply

• Mar 16, 2015 - 14:18

The very same thing happens at lines 1164-1165 of mscore/scoreview.cpp
{syntaxhighlighter brush:c++;first-line:1163;} if (drumsetEdit.exec()) {
_score->undo(new ChangeDrumset(staff->part()->instr(), drumsetEdit.drumset()));
mscore->updateDrumTools();
}{/syntaxhighlighter}

Reply