Crash by changing language after loading a template

• Nov 1, 2018 - 11:24
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S1 - Blocker
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 0128daf

Steps:
1) Load a template, eg Grand Staff
2) Edit -> Preferences -> Language: toggle to another language -> OK

Result: crash

  • Note: No crash when changing language with the default "Untitled" score.

Comments

• Nov 1, 2018 - 11:50

Confirmed. Questionable whether this is a regression (2.x didn't crash, but also didn't allow changing translations on the fly, it required a restart for the change to take effect, which master does not)

I don't get any (meaningfull) stack trace, just a SIGSEV

Reply

• Nov 6, 2018 - 15:44

The issue is very strange. In fact, it is not related to language: you can change any other preference or change actually nothing and just press OK right after opening the preferences screen and the application will crash. This is not related also to templates: you can open a new file dialog, cancel it without creating anything, open and confirm preferences and MuseScore will still crash.

The reason of the crash is somewhere in the interaction of NewWizard and QApplication::setStyle. If I remove all pages from NewWizard (by disabling all setPage calls in newwizard.cpp) the crash does not happen. If I move QApplication::setStyle away from MuseScore::updateUiStyleAndTheme and call it only once in the main() function the crash does not happen. Still disabling setting those css sheets which are pointed at by the crash backtrace does not help in preventing the crash. I wasn't able to locate the actual reason of the crash so far.

Anyway there are at least two options to fix this issue:
1) Create NewWizard each time when it is needed instead of storing a pointer to its instance inside MuseScore. This just removes that wizard from the scene when the crash usually happens but this also requires MuseScore to do all the work on the dialog creation from scratch each time. Or we can try not to set MuseScore as its parent though I am not sure styles will work correctly in that case.
2) Move QApplication::setStyle call away from MuseScore::updateUiStyleAndTheme and call it only once in the main() function. This works but it is not clear why it works so the actual problem can still persist. If we don't discover the real reason of the crash for some time we can apply this as a temporary fix.

So I don't know exactly what happens here but I hope my observations will help someone who will be debugging this or at least myself in the nearest future.

Reply