With GDK_BACKEND=wayland we get: (gnome-control-center:15499): Pango-CRITICAL **: 11:23:18.476: pango_layout_get_pixel_extents: assertion 'PANGO_IS_LAYOUT (layout)' failed (gnome-control-center:27758): Gdk-WARNING **: 11:11:37.384: Native Windows wider than 65535 pixels are not supported (gnome-control-center:27758): Gdk-CRITICAL **: 11:11:37.418: (gnome-control-center:30959): Gdk-CRITICAL **: 11:13:39.987: /var/tmp/portage/x11-libs/gtk+-3.24.4/work/gtk+-3.24.4/gdk/wayland/gdkdisplay-wayland.c:1321: Truncating shared memory file failed: Invalid argument Followed by a segfault. With GDK_BACKEND=x11 we get: (gnome-control-center:5689): Pango-CRITICAL **: 11:17:51.242: pango_layout_get_pixel_extents: assertion 'PANGO_IS_LAYOUT (layout)' failed (gnome-control-center:1963): Gdk-WARNING **: 11:15:45.701: Native Windows wider or taller than 32767 pixels are not supported (gnome-control-center:1963): Gtk-WARNING **: 11:15:45.744: infinite surface size not supported And then no window actually appears (in gnome shell an outline can sometimes be seen in overview mode). Both issues happen about every second time gnome-control-center is started on one system and every time on another. The pango layout assertion failure occurs always however, even in cases the window finally shows. Downgrading to x11-libs/gtk+-3.24.1 fixes it. I tried to recompile pango and gnome libraries but this did not help.
There's some sort of combobox placement fixes in 3.24.4 (and I think in the 3.24.3-r1 patchset too) for wayland; maybe those are bad - should discuss with upstream. Probably this isn't an issue with newer gnome-control-center, but gtk+ shouldn't be breaking apps regardless, unless they are relying on some undefined behaviour or something. Do you have some long text comboboxes in there, that maybe most people don't?
To know where to look for upstream gnome-control-center past 3.26 to possibly backporting something, would be good to know at least in which panel you have such comboboxes, to find the relevant stuff quicker; if that's the problem in the first place, that is.
Thanks for the quick response! As I wrote, it's not a problem with wayland but apparently with the pango layout engine. Only the effect is slightly different (wayland segfaulting, X11 not showing a usable window). It's interesting that most other gnome programs work without problems. I tried several gnome games, gnome-disks, gnome-editor, gnome-calculator - no trace of a pango layout problem. I don't understand what you mean by me having long text comboboxes in gnome-control-center. It appears to be a problem of the main window, which is subdivided in an icon/text bar on the left and an (originally empty) settings box on the right. I did suspect it to depend upon German umlauts being present in the left box but when I set LANG=C the problem persists despite the language being English in those instances in which the window becomes visible.
I found one more program with problems: gnome-base/dconf-editor-3.28.0 Here I get the pango layout messages when using the software, usually not directly at startup. Within the /system/locale/region panel for example, the switch to use default values appeared empty at first and then, upon clicking became so large that it covered the whole window. Same fix here: Downgrade to x11-libs/gtk+-3.24.1.
I meant that this went into 3.24.4, and it felt relevant to the problem (as it was about long text comboboxes): https://gitlab.gnome.org/GNOME/gtk/merge_requests/514 But I guess it only would be something that affects things once you actually click on a combobox to open up the popup, so nevermind that. Can you try with 3.24.3 without the patchset I had in -r1, and if that still fails, then also 3.24.2? So we can narrow down when things changed for the worse for you. I think blind copies of the ebuilds should work good enough for testing purposes. I assume this isn't a problem on X11 at all, but only native wayland?
I have now narrowed everything down specifically to GtkSwitch elements! gnome-control-center's topmost entry here is 'bluetooth' with a switch in the upper right corner, which will cause the problem. x11-libs/gtk+-3.24.2: Working fine x11-libs/gtk+-3.24.3: All GtkSwitch'es show strange glyphs where the labels should be but no pango warnings x11-libs/gtk+-3.24.4: Reported pango layout engine warnings, GtkSwitch not visible if the window shows at all "I assume this isn't a problem on X11 at all, but only native wayland?": No, as I wrote the problem occurs with both X11 and wayland renderers, only with different symptoms.
Created attachment 562570 [details, diff] Try non-unicode GtkSwitch glyphs too What happens if you apply this test patch to gtk+-3.24.4? On that note, the file that it patches - do you see at least some of the glyphs in those arrays with gedit (not the ones that this patch add) or some such in tarball sources unpack?
(In reply to Mart Raudsepp from comment #7) > Created attachment 562570 [details, diff] [details, diff] > Try non-unicode GtkSwitch glyphs too > > What happens if you apply this test patch to gtk+-3.24.4? > > On that note, the file that it patches - do you see at least some of the > glyphs in those arrays with gedit (not the ones that this patch add) or some > such in tarball sources unpack? Actually - looking at the patch in your browser should be sufficient too for that glyph check - do you see some visible glyphs in the quotes in front of the U+xxxx comments, or boxes with hex inside?
basically a screenshot of looking at the attached patch in firefox would be nice to see :)
Created attachment 562580 [details] Screen shot in chromium
Odd. This suggests the problem isn't what I'm thinking. Can you try the patch regardless?
Created attachment 562582 [details] Screen shot in firefox So here are screenshots in both chromium and firefox. At least the first glyph seems missing when seen in firefox. But the patch fixes the error, thanks a lot! Doesn't look particularly pretty but no more pango layout warnings or crashes. Can you tell me why this error occurs now? In 3.24.2 these glyphs worked, didn't they? Should I add or enable specific fonts?
I don't see the primary glyhs either; just the fallback glyphs (the middle one after the patch). Same for you, but for me there are no crashes. For me I end up using cantarell font; what font is used can be checked with the live GtkInspector, but fallbacks are enabled there, so if that font doesn't have it, then pango/freetype/fontconfig should find a font that does have it, just like you see in firefox. The patch was to test if things work if some basic characters are used instead, which all fonts have. But that shouldn't have been the case for you, as you do see them in firefox. Maybe try in gedit or something, in case chromium and firefox are shipping extra fonts locally that have it, but your system doesn't have them.
gedit displays the middle glyph fine as well... There must have been a change in the logic how the glyphs are checked for acceptability, right? Within GTK+, and in a way that is fairly specific to GtkSwitch. After all, downgrading GTK+ without any change in Locale or installed fonts (or pango or fontconfig) fixes it. Wait: In 3.24.2 the GtkSwitch'es normally show localised text labels instead of the fallback glyphs. That is they show ON/OFF or AN/AUS. Maybe the fallback problem would actually hit most people, but because "ON/OFF" are normally used it doesn't show. Now why are the localised labels not used with 3.24.3 or 3.24.4 on this system?
3.24.2 has translatable ON/OFF, and many languages translated it to those fallback glyphs that you do see in firefox. 3.24.3 was going to switch to outright these glyphs you see, but instead it got merged with the new primary glyphs instead (IEC power control unicode glyphs from unicode 9.0 standard), so 3.24.3 for many people (mainly those that don't have noto fonts installed) saw the fallback hex glyphs instead, as no font provided the glyphs. 3.24.4 (and my 3.24.3-r1 patchset) added the fallback logic, which starts calling these pango_layout_* APIs to find out if the tried glyphs were found, or the fallback hex box used - and tries them in order in the arrays. For you, it appears as if both upstream glyphs for each are found to fallback (even though they appear present in gedit and firefox), and then you probably hit some problems in the code not gracefully handling none of the glyphs found to be existing (which is why my patch "fixes" it - by using ASCII chars that all textual fonts should have). Can you find out what font you are using there in GTK+, as it doesn't appear to be cantarell? https://wiki.gnome.org/Projects/GTK/Inspector tells how to open up the gtk inspector. With the top-left button ("Select an Object") choose a GtkSwitch; then in the inspector instead of "Miscellaneous", look at "CSS nodes"; a "switch" node should already be selected, then on the right there are CSS properties listed - what's the value for "font-family" for you, when it doesn't work?
Created attachment 562592 [details] Screenshot of the GTK Inspector That's "Cantarell". But look at the screen shot of the "Misc" window for the switch - that's also full of awkward glyphs...
and you do have cantarell installed?
Yes, media-fonts/cantarell-0.111 qlist cantarell /usr/share/fonts/cantarell/encodings.dir /usr/share/fonts/cantarell/fonts.dir /usr/share/fonts/cantarell/fonts.scale /usr/share/fonts/cantarell/Cantarell-Thin.otf /usr/share/fonts/cantarell/Cantarell-Regular.otf /usr/share/fonts/cantarell/Cantarell-Light.otf /usr/share/fonts/cantarell/Cantarell-ExtraBold.otf /usr/share/fonts/cantarell/Cantarell-Bold.otf /usr/share/doc/cantarell-0.111/NEWS.bz2 /usr/share/doc/cantarell-0.111/README.md.bz2 /usr/share/metainfo/org.gnome.cantarell.metainfo.xml
Can you please try the patch from upstream, that fallbacks to empty glyphs for now? https://gitlab.gnome.org/GNOME/gtk/commit/6a4ce55a69c5ecbbf06bc905ac0bfdd04f64bb66.patch Ideally reporting back on the upstream MR link (link I put in URL) Looking closer, it seems like cantarell doesn't have either of the ON glyphs (the pipe-like one), only the secondary OFF circle. So this would be an issue, when no other fonts ship them, but clearly for you something does, as you can see the glyphs in gedit. Why it behaves like that for you remains a mystery. But that patch should at least solve it breaking things fully - to simply not have one or both of the glyphs instead, yet still see if it's ON or OFF at least based on the color and position. A future gtk version may instead start using icons there, to not hit such issues.
Created attachment 562620 [details] Screenshot with GtkSwitch'es (Archive Manager settings) That patch interestingly works as well and does not lead to empty labels but I/O labels (see shapshot). Dunno why.
Are you sure something else didn't change? Like in debugging having some fonts installed or something? Or put otherwise - is it broken again if all you do is re-emerge gtk without any of the gtkswitch patches?
I now checked back and forth - the unpatched x11-libs/gtk+-3.24.4 from the tree produces the error, and the version with the patch (empty strings) shows the apparently correct I/O symbols (the second entries). I was pretty sure that there must be an off-by-one error somewhere but checking gtkswitch.c it is clear that the first glyph with unknown_glyphs_count==0 is taken. I'm on gcc 8.2.0, but this would be too "unsubtle" for a compiler bug at this stage I guess. Are you sure that G_N_ELEMENTS (on_glyphs) really returns 2 and not 1 in the unpatched case? Should I check?
Sorry, I'm rather busy personally until Sunday or so. I suggest to take the discussion to the upstream merge request found in the URL field of this bug. Or maybe as it's merged now, a new issue.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=218e1198f3988f587725d166430b16332ca47a5f commit 218e1198f3988f587725d166430b16332ca47a5f Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-02-07 09:49:49 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-02-07 11:25:54 +0000 x11-libs/gtk+: Further fallback fixes for GtkSwitch unicode glyphs Add a final fallback to no glyphs at all, so if the glyphs aren't found, it'll at least just not use any and not mess up layout and stomp on some memory, etc. The ON or OFF position should still be visible from color and position, at least, but for most people at least the secondary glyphs should be available. gtk+-3.22.5 changes all this to icons, but it also changes the default theme look, so we do this simpler patch for 3.22.4 for that to be the next stable candidate soon, instead of theme changing 3.22.5. Closes: https://bugs.gentoo.org/676098 Package-Manager: Portage-2.3.52, Repoman-2.3.12 Signed-off-by: Mart Raudsepp <leio@gentoo.org> .../files/3.24.4-more-gtkswitch-fallback.patch | 34 ++++++++++++++++++++++ .../{gtk+-3.24.4.ebuild => gtk+-3.24.4-r1.ebuild} | 5 ++++ 2 files changed, 39 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eea11c992629ffb545ef4f0561bb2282b5391117 commit eea11c992629ffb545ef4f0561bb2282b5391117 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-02-07 11:25:35 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-02-07 11:25:57 +0000 x11-libs/gtk+: bump to 3.24.5; includes theme refreshes Uses icons for GtkSwitch now; though the default theme hides them with its refresh and redesign - but other themes will shown them from icon files now, instead of problematic unicode glyphs. Bug: https://bugs.gentoo.org/676098 Package-Manager: Portage-2.3.52, Repoman-2.3.12 Signed-off-by: Mart Raudsepp <leio@gentoo.org> x11-libs/gtk+/Manifest | 2 + x11-libs/gtk+/gtk+-3.24.5.ebuild | 234 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 236 insertions(+)
