Summary: | blueman and xfce4-power-manager crash when opening right-click menu while terminus is set as system font | ||
---|---|---|---|
Product: | cairo | Reporter: | Alex-Daniel Jakimenko <alex.jakimenko+cairo> |
Component: | general | Assignee: | Chris Wilson <chris> |
Status: | RESOLVED MOVED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | major | ||
Priority: | high | CC: | agomez, bitlord0xff, mmokrejs, monsta, simon, stephen.j.boddy |
Version: | 1.12.16 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=159468 https://bugs.freedesktop.org/show_bug.cgi?id=85141 |
||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
trace
test case to reproduce the failed assertion |
Description
Alex-Daniel Jakimenko
2014-05-16 16:48:38 UTC
I believe the extent of this bug might be much bigger than described in the OP, namely including possibly any bitmap font in combination with a lot of programs using cairo. On my system, a lot of Gtk2 programs crash when a bitmap font is set as "gtk-font-name" in $HOME/gtkrc-2.0. Example: 1. Set "gtk-font-name="Unifont 16"" in $HOME/gtkc-2.0. 2. Call "leafpad" from the command line. -> Immediate crash. Command line output: leafpad: cairo-scaled-font.c:459: _cairo_scaled_glyph_page_destroy: Assertion `!scaled_font->cache_frozen' failed. The same happens with the programs pyroom, claws-contacts, gvim, poedit, sylpheed, but n o t with gtk2fontsel, lxappearance and osmo. Other bitmap fonts leading to this error: Lucida, Utopia (both from Xorg fonts), hlv (from M+ fonts), Dina. I am running Arch Linux, cairo version 1.12.16 (currently with the Infinality Ultimate Patches, but I did some spot checks with vanilla cairo as well yesterday: same results), Gtk2 version 2.24.24. I also have similar problem with xfce4-panel crashing when application (in my case web browser) sets specific title. Possibly related bug reports downstream: https://bugzilla.xfce.org/show_bug.cgi?id=10616 https://bugzilla.xfce.org/show_bug.cgi?id=10344 https://bugzilla.xfce.org/show_bug.cgi?id=11300 Using x11-libs/cairo-1.12.16 Created attachment 110466 [details]
trace
Sorry for the "me too" but this also affects Terminator which I work on, and someone raised this for the whole Xubuntu xfce desktop at: https://bugs.launchpad.net/bugs/1294699 I'm the one who reported this on launchpad vs. XFCE/Xubuntu. This affects others as well, I'm bumping this old bug up a notch because it's a huge blocker for desktop users. The effect is that an ordinary Xubuntu/XFCE user can change the system font to fixed width, and then the desktop crashes and crashes every time they try to log in, unless they change desktop or log in command line and edit an XML file. Other applications have similar crashing issues on this assert. I was able to reproduce this crash with gimp and cairo from git master. On fedora 22, I have installed 'gnome-themes', 'gnome-themes-legacy' and 'gtk-murrine-engine'. I have put in ~/.gtkrc-2.0 these three lines: include "/usr/share/themes/MurrinaEalm/gtk-2.0/gtkrc" style "myfont" { font_name = "Terminus 11" } widget_class "*" style "myfont" gtk-font-name = "Terminus 11" and use the this command line to start gimp-2.9 installed in $HOME/prefix GTK_PATH=$HOME/prefix/lib64/gtk-2.0:/usr/lib64/gtk-2.0 gimp-2.9 The problem is that in src/cairo-scaled-font.c _cairo_scaled_glyph_lookup is called with the 'scaled_font->cache_frozen' TRUE: http://cgit.freedesktop.org/cairo/tree/src/cairo-scaled-font.c#n2961 but when scaled_font_backend->scaled_glyph_init returns for example CAIRO_INT_STATUS_UNSUPPORTED http://cgit.freedesktop.org/cairo/tree/src/cairo-scaled-font.c#n2982 (which comments suggest being not an error) http://cgit.freedesktop.org/cairo/tree/src/cairo-scaled-font.c#n3022 _cairo_scaled_glyph_page_destroy is called (via _cairo_scaled_font_free_last_glyph) which expects scaled_font->cache_frozen being FALSE. thawing the cache before calling _cache_scaled_font_free_last_glyph and freezing it after fixes the crash, perhaps introducing races in multi threaded programs. Bug 85141 also has the same problem with getting the assertion at cairo-scaled-font.c:459. I'm not sure what the correct fix is. A fix for this problem (not for the case of corrupted/fuzzed font files) could be to pass only CAIRO_SCALED_GLYPH_INFO_METRICS when scaled_font->backend->scaled_glyph_init is called to insert the not yet cached glyph in the hash_table, basically removing 'info | ' here: http://cgit.freedesktop.org/cairo/tree/src/cairo-scaled-font.c#n2984 if it was requested also the path info it is filled in the second call: http://cgit.freedesktop.org/cairo/tree/src/cairo-scaled-font.c#n3000 whose UNSUPPORTED failure path gracefully propagates the status Another simple fix is for the murrine gtk theme engine, here: https://github.com/GNOME/murrine/blob/master/src/murrine_style.c#L2172 it should be inserted a call to pango_cairo_update_layout (cr, layout). IIUC, usually pango_cairo inserts glyphs in the scaled_font cache during the layout preparation, that is querying glyph extents and so only using text metrics info (which does not fail, unless fuzzed font files), but if you change cairo's transform matrix, cairo is using stale layout info with a different scaled_font, and so it inserts the glyphs while querying path info which fails for bitmap fonts and the failure code path is wrong. Created attachment 119194 [details]
test case to reproduce the failed assertion
The attached program requires the terminus font.
It shows that removing the 'info | ' from src/cairo-scaled-font.c
at line 2984 prevents the assertion, but the text is stroked
displaced compared to uncommenting pango_cairo_update_layout,
which alone avoids the failed assertion.
I have this same problem with GIMP combined with the Terminus font. It would just say: (gimp:3713): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error gimp: cairo-scaled-font.c:459: _cairo_scaled_glyph_page_destroy: Assertion `!scaled_font->cache_frozen' failed. gimp: terminated: Aborted and exit the program right after startup. I'm running Arch Linux with cairo-infinality-ultimate 1.14.4-1, and Gtk2 version 2.24.28-1. Hi Massimo, Thanks for the proposed solution, it works fine, no more crashes in any Xfce or MATE apps. Unfortunately, murrine is dead upstream for years, so the patch should be applied in the distros. So, me and other people sent the patch to the following distros: Debian: https://bugs.debian.org/827134 Ubuntu: https://bugs.launchpad.net/bugs/1294699 Arch: https://bugs.archlinux.org/48294 Fedora: https://bugzilla.redhat.com/1310313 The patch is also in the attachment at: https://github.com/mate-desktop/mate-panel/issues/328#issuecomment-186539988 Is this a bug in cairo, or not, then?(In reply to Massimo from comment #6) > (which comments suggest being not an error) > http://cgit.freedesktop.org/cairo/tree/src/cairo-scaled-font.c#n3022 Maybe I am misunderstanding but, is this a bug in cairo or not? An assert triggered in private API suggest that it is a bug in cairo. (In reply to Andrés Gómez García from comment #13) > Is this a bug in cairo, or not, then?(In reply to Massimo from comment #6) > > (which comments suggest being not an error) > > http://cgit.freedesktop.org/cairo/tree/src/cairo-scaled-font.c#n3022 > > Maybe I am misunderstanding but, is this a bug in cairo or not? > > An assert triggered in private API suggest that it is a bug in cairo. IIRC it is a bug in cairo that, in few cicumstances, can be prevented by the caller, calling pango_cairo_update_layout before calling pango_cairo_layout_path. Above I meant that scaled_font->backend->scaled_glyph_init (...) returning CAIRO_INT_STATUS_UNSUPPORTED is not an error (as stated by cairo developers in comments), (IOW it is not a user font code violating a pre/post-condition/contract) and so should not lead to a failed assertion @Massimo, Vlad: While the crashes are fixed the function that draws the text-shadow in murrine is now broken and all themes that use the "text-shadow" option now have a distorted or displaced shadow. If this is a bug in cairo (as suggested), I would like to suggest to either fix it there or to improve the workaround in Murrine so that there is no regression. (In reply to Simon Steinbeiss from comment #15) > @Massimo, Vlad: While the crashes are fixed the function that draws the > text-shadow in murrine is now broken and all themes that use the > "text-shadow" option now have a distorted or displaced shadow. > > If this is a bug in cairo (as suggested), I would like to suggest to either > fix it there or to improve the workaround in Murrine so that there is no > regression. Regarding a Murrine improvement, the easy thing to try is to add a call to pango_cairo_update_layout (cr, layout) also in the if branch after cairo_translate(...) and before pango_cairo_show_layout (cr, layout); here: https://github.com/GNOME/murrine/blob/master/src/murrine_style.c#L2164 it seems the only other place where a pango_cairo function is called. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/41. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.