Crash when changing to Gonville font [Linux]
Ciao.
I don't know if also someone else is seeing this, but whenever I try to switch to Gonville in my personal build under Linux Mint 13, MuseScore crashes.
Commit: 4af604cb5 self-compiled under Linux Mint 64bits, with Qt 5.2.1 (64bits).
My Linux Mint runs inside VirtualBox.
Steps:
1- Open Promenade example;
2- Style -> General... -> Musical symbols font: -> Gonville -> Ok.
I tried with debug and release build but it crashes for both.
Does it happen only for me?
Attached the logs from address sanitizer (it crashes also when address sanitizer is not enabled).
The crash does not happen for Emmentaler or Bravura; I noticed that MuseScore does not go through Ms::ScoreFont::load() routine when changing to those fonts (it goes through this routine when starting).
The crash does not happen for my Windows personal build nor for the official Nightly builds.
It happens since some commits (maybe also weeks?), but I could not pin down the one which caused the crash to appear.
Ciao,
ABL
Attachment | Size |
---|---|
gonville_crash_AddSan.txt | 4.55 KB |
Comments
Bravura is used by default in the palette. That's why it's loaded right away. Emmentaler is used by the demo score. Gonville is not used until the user changes to it.
The interesting lines are missing from the log :( it crashes on this line https://github.com/musescore/MuseScore/blob/master/libmscore/sym.cpp#L4… calling QFontDatabase::addApplicationFont but we don't see why.
Can you check if you can open Gonville.otf with a font utility on your Linux. Maybe the font is "corrupted" ?
In reply to Bravura is used by default in by [DELETED] 5
I was able to open Gonville with FontForge and it seems ok. Attached a screenshot comparing one character in Gonville and Bravura.
I tried to clone again the github repository in a new folder (just in case mine got corrupted), but I still get the crash after a new compilation.
Now I am trying to debug with gdb. I will let you know if I obtain some results.
Edit: I forgot the attachment...
In reply to Fontforge by ABL
with the nightly of to day
4af604c
Mint16 64bits
and it was yet the case with 77f7d29 which I compiled on feb1st
Here is the gdb backtrace.
It seems that
_textElement
is 0 at line 272 of mscore/texttools.cpp and therefore the problem.There is something strange: when the font is changed to Bravura or to Emmentaler the breakpoint at line 272 of mscore/texttools.cpp is not hit; this breakpoint is only hit when the font is changed to Gonville.
Commit: 4af604cb5 self-compiled under Linux Mint 13 (64bits)
P.S: At least I am not the only one seeing this crash...
In reply to gdb backtrace by ABL
With gdb under Windows it does not hit the breakpoint I set at line 272 of mscore/texttools.cpp with any of the font (Emmentaler, Bravura or Gonville) when they are changed in Style -> Set general style...
It seems that the position in the code where the font is loaded influences the crash.
Bravura is loaded on creating the palette, as lasconic said.
Emmentaler is loaded at line 292 of libmscore/score.cpp:
_scoreFont = ScoreFont::fontFactory("emmentaler");
If this "emmentaler" string is substituted by "Bravura", then Emmentaler is loaded only when an Emmentaler score is loaded and if I set MuseScore to open with empty score, load a Bravura score (precedently saved) and then switch to Emmentaler, I obtain the same crash that I see with Gonville.
If this "emmentaler" string is substituted by "Bravura" and MuseScore is set to open with empty score, loading an Emmentaler score (precedently saved) does not crash the application.
As a workaround, I added
_scoreFont = ScoreFont::fontFactory("Gonville");
just before line 292 of libmscore/score.cpp (so that it is then overwritten by "emmentaler") and I do not see the crash anymore.
As a side effect, Gonville is now also available in the dropdown list of text fonts when editing text (before this small change, among the built-in fonts only Bravura and MScore = Emmentaler, previously loaded, were available).
This change however does not really solve the problem, but just avoids it by pre-loading Gonville.
In reply to Position in the code by ABL
Would a test to make sure that _texttool is not null be enough ?
if (!_textool) return;
https://github.com/musescore/MuseScore/blob/master/mscore/texttools.cpp…
In reply to Would a test to make sure by [DELETED] 5
Yes, of course.
My first trial was to comment out the content of updateText and Gonville worked, but this prevented font changing in text edit mode (even if at the moment it does not make a big difference since some text edits do not work either for styled or unstyled text).
But I am still wondering why only under Linux we have this behavior and only when the font is loaded after a score is loaded.