3.5 Alpha

• May 7, 2020 - 05:19

OS: Linux Mint 19.3, Arch.: x86_64, MuseScore version (64-bit): 3.5.0, revision: 1ee2fe3
Edit/Preferences->OK->Crash
:(
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.11614, revision: 1ee2fe3
The same.


Comments

In reply to by Jojo-Schmitz

Found some cases.
It is not only about old settings.

1) Setting "Start empty"
In this session ewerything works. But when you exit and start program again, You are in "crashing" mode, described above. (In dosent metter, if this option was set in old version, or after factory reset in 3.5.)

2) Something with locales. I cannot reproduce it, bu I have feeling, it is connected with locales settings (I had "system" language set and changed it to "english" in older version and may be som of this special combinations could make 3.5 goes into crash mode. but now, I cannot reproduce it anymore.

In reply to by Shoichi

The info from Crash Reporter:

0   MuseScore3.exe                  0x14020fbd1         Ms::SmoothPanSettings::loadFromPreferences() (C:\MuseScore\mscore\scoreview.cpp:5333)
1   MuseScore3.exe                  0x14022ff3a         Ms::PreferenceDialog::apply() (C:\MuseScore\mscore\prefsdialog.cpp:1213)

I can confirm the crash over here as well (Win10 x86_64)
I took a copy of my preferences file before installing, so let's see if I can locate something that way.

In reply to by jeetee

OK, so the first thing that was very in my face is that the theme changed my MuseScore font (possibly a consequence of the new loading splash screen?)

Before:
theme\fontFamily=MS Shell Dlg 2
theme\fontSize=8

After:
theme\fontFamily=Segoe UI
theme\fontSize=9

Then there are a few new settings added to the file (so those are likely not the cause of the crash, as they're saved):
* in the [import] section: compatibility\resetElementPositions=Ask
* in the [score] section: harmony\play=false and harmony\play\onedit=true

On a second run the crash can still be reproduced and the ini file is no longer changed (so likely crashing on the same point)

In reply to by Jojo-Schmitz

I don't think this crash has anything to do with that fix.

Concidentally, I experienced this exact same crash yesterday, and it happened while I was running inside a debugger. So I took a look.

The crash occurred inside the call from this line:

svPanSettings->loadFromPreferences();

As far as I could tell, the crash was caused by the svPanSettings pointer containing a garbage value (not nullptr).

I restarted the app with a breakpoint set a few lines earlier so I could see try to see why it was happening, but I was never able to reproduce the crash again.

Just noticed that SmoothPanSettings::loadFromPreferences() is nullptr-checking mscore->currentScoreView(), but the line setting svPanSettings in the first place is not:

SmoothPanSettings* svPanSettings = mscore->currentScoreView()->panSettings();

Very suspicious.

In reply to by jeetee

OK, what is very clear is that reset to default "fixes" this crash.
What is also clear is that reset to default simply erases a bunch of settings (perhaps entire groups) and that if you afterwards press OK in the preferences window many settings are now added into the preferences file as if you've changed them to a value which happens to be the default.

So far no clear culprit yet. Dayjob is asking some attention now, so I can't further pursue. Attached are my various versions of the ini-file in case someone else wishes to dive in.

Do you still have an unanswered question? Please log in first to post your question.