Created attachment 159979 [details] Backtrace The following requires a debug LO build coupled with LO Online to trigger. The assert seems to indicate some kind of font fallback handling problem, so far I found the following fonts trigger it: Fira Mono, Fira Sans, Optima, TeX Gyre Adventor (and probably other Tex Gyre ones), Vegur. - Open a document in LOOL. - Open Format -> Character, and choose one of the above fonts in the font list. => Crash with assertion failure when it tries to render the preview. There's no crash if a non-debug LO build is used (and the preview is still shown). The console shows the following assert: "vcl/unx/generic/gdi/freetypetextrender.cxx:166: virtual std::unique_ptr<GenericSalLayout> FreeTypeTextRenderImpl::GetTextLayout(int): Assertion `mpFreetypeFont[nFallbackLevel]' failed." Attaching backtrace. The bug could perhaps be reproduced just with a core build in some way, but I haven't found how. Opening the Character properties dialog in gtktiledviewer, and switching to one of the reproducer fonts there doesn't trigger assert. Briefly the assert was triggered upon document load, but that's fixed (see bug 132424). The assert was added with the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=8d7435aa72af7fd0b454d7314c6c79f61f112679 author Jan-Marek Glogowski <glogow@fbihome.de> 2019-01-23 19:59:45 +0100 committer Jan-Marek Glogowski <glogow@fbihome.de> 2019-01-25 19:03:55 +0100 "Assert missing SalGraphics font on GetTextLayout" Two details I don't understand: - why does it only trigger in LOOL? - since it looks like the fonts can be rendered, what is actually going wrong?
Interestingly nFallbackLevel is 0 in your backtrace, so it's not even about any fallback, as this means there isn't any font set. Which even makes less sense for the font preview, as that should just list already known / enumerated fonts. I think the "fix" for bug 132424 may simply paper over the real problem. If the same happens for loading documents without that fix, that somehow means font handling isn't working correctly at this point. Guess someone needs to look into the original weld patch and see what is different now.
(In reply to Jan-Marek Glogowski from comment #1) > I think the "fix" for bug 132424 may simply paper over the real problem. If > the same happens for loading documents without that fix, that somehow means > font handling isn't working correctly at this point. Guess someone needs to > look into the original weld patch and see what is different now. Right, what Caolán wrote there is that the assert is actually unrelated to the weld patch, it just became triggered at a different time. I could verify that right before the weld patch it could be triggered with the same repro steps as in the description above, thus the patch identified in bug 132424 is irrelevant when it comes to the assert.