| Summary: | x11-libs/gtk+: Crash with glib/gspell support due to invalid function pointer | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hanno Böck <hanno> |
| Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander, gentoo-bugs, python |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| URL: | https://gitlab.gnome.org/GNOME/gtk/issues/1556 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 651616 | ||
| Attachments: |
example python script that crashes
stack trace from gdb glib-crash.c |
||
Created attachment 562306 [details]
stack trace from gdb
What version of enchant do you have installed? enchant 1.6.1 (aka latest non-masked version). Updating it seems troublesome given there's still plenty of incompatibilities (#629838). I have seen people mentioning enchant as the culprit, yet I couldn't see any evidence of that. Well, you can try to delete or move "/usr/lib*/enchant/libenchant_zemberek.so" and see if this fix the issue. Created attachment 564046 [details]
glib-crash.c
I tracked this down more, I can reproduce it by rewriting a simple example without python and gtk, only using glib and gspell.
On a different system this doesn't crash.
What seems to happen is that some library is dlopen'ed and then dlclose'd and then some memory access happens into that library.
@Alexander Tsoy: Removing zemberek indeed makes this issue disappear, but that doesn't really tell us a whole lot on how to fix it and doesn't even necessarily mean the bug is in gspell/zemberek. I believe something with the loading of the gspell-modules is borked.
zemberek checks in the non-masked version of enchant seem to be bad. If it finds dbus-glib, it'll enable it. And then it probably talks with zemberek over DBus, and crashes if it finds it?
The configure result also outputs:
"The Zemberek Turkish spell-checking plugin is enabled. It is known
to cause crashes with WebKit. Use at your own discretion."
and
Build Zemberek backend: yes
despite it meant to not be built anymore. This is bug 662484.
Do you have only zemberek installed, or also last-rited zemberek-server? Not that I know which one actually provides the dbus stuff it might end up using.. or maybe it crashes regardless of something on the other end of the dbus calls.
Anyhow, just my thoughts dump, maybe it sheds some light to your case.
x11-libs/gtk+-3.24.5 contains the fix @pacho: No, this GTK+ bugfix does not resolve this issue. I found GTK+ bug 1556 while trying to debug this issue with ASAN, but I believe it's just a conicidence and bug 1556 was ultimately just something found on the way. (It's good that it is fixed nevertheless of course, but the crash persists with latest GTK+.) Note that also gtk+ 3.24.4-r1 is likely the next stable candidate, not 3.24.5, because 3.24.5 changes the theme, which is meant for GNOME 3.32, not earlier. So if that fix in 3.24.5 is still important enough, we might want to backport that too, together with any other fix to solve it fully (should it be something to patch in gtk+) (In reply to Hanno Boeck from comment #8) > @pacho: No, this GTK+ bugfix does not resolve this issue. > > I found GTK+ bug 1556 while trying to debug this issue with ASAN, but I > believe it's just a conicidence and bug 1556 was ultimately just something > found on the way. (It's good that it is fixed nevertheless of course, but > the crash persists with latest GTK+.) And did you report your crash to upstream? (to let us track the issue) I wouldn't be even sure the problem is in glib, not gspell. fwiw, I plan to look into this and other spell related things deeper once I get to untangling this enchant-2 mess. (In reply to Pacho Ramos from comment #10) > And did you report your crash to upstream? (to let us track the issue) I don't know which upstream. It's some kind of interaction of glib, gspell and enchant, but I haven't figured out enough to know which part is responsible. But basically this and bug 662484 are the same, right? In this bug you just are trying to chase a potential deeper issue, instead of just avoiding it by ensuring zemberek provider isn't there to trigger it? All my applications that use gtk+:3 crash on file open/save dialog. x11-libs/gtk+-3.24.5::gentoo was built with the following: USE="X cups introspection xinerama (-aqua) -broadway -cloudprint -colord -examples -gtk-doc -test -vim-syntax -wayland" ABI_X86="32 (64) (-x32)" putty (putty:23066): dbind-WARNING **: 01:35:04.416: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (putty:23066): Gtk-CRITICAL **: 01:35:05.174: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar (putty:23066): Gtk-CRITICAL **: 01:35:05.180: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar (putty:23066): Gtk-CRITICAL **: 01:35:05.184: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar munmap_chunk(): invalid pointer Abgebrochen transmission-gtk (transmission-gtk:15808): dbind-WARNING **: 01:42:13.802: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. free(): invalid pointer Abgebrochen Looks like I get this too with gedit[spell] and the spellchecker plugin enabled. But it only crashes upon application shutdown there (In reply to jospezial from comment #14) > All my applications that use gtk+:3 crash on file open/save dialog. I don't see any relation to the concrete case that is being investigated as part of this bug entry So with gedit the crash can also happen when unloading the spell plugin. The problem seems to be that a GSource has been sort of deleted, but it is still being iterated. It hits a GSource that has its source_funcs pointers point to bad memory, and trips up on source->source_funcs->prepare specifically. Looks like some GSource (timeouts, idle handlers, whatnot) cleanup problem somewhere in gspell or its lower level spellchecking deps... Building enchant without zemberek provider fixes the gedit issue for me too. So there's some GSource mess-up in that dbus-glib using code, at least when there's nothing (zemberek-server) providing the dbus stuff it uses. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3ccd9aa1149fdebc3a2ec1a7f7d969afe4b2fd77 commit 3ccd9aa1149fdebc3a2ec1a7f7d969afe4b2fd77 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-03-12 11:33:51 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-03-12 11:44:50 +0000 app-text/enchant: really disable zemberek provider to avoid crashes Something trips up GSource iteration in main context with the zemberek provider. As we don't have zemberek-server anymore, just make sure it is not build wrongly due to configure bugs. Bug: https://bugs.gentoo.org/662484 Closes: https://bugs.gentoo.org/675908 Package-Manager: Portage-2.3.52, Repoman-2.3.12 Signed-off-by: Mart Raudsepp <leio@gentoo.org> app-text/enchant/enchant-1.6.1-r1.ebuild | 59 ++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) (In reply to Mart Raudsepp from comment #16) > (In reply to jospezial from comment #14) > > All my applications that use gtk+:3 crash on file open/save dialog. > > I don't see any relation to the concrete case that is being investigated as > part of this bug entry My bug was caused by x11-libs/cairo-9999 . It seems to be fixed upstream in cairo git now. Returning to x11-libs/cairo-1.16.0-r2 fixes this for www-client/firefox-bin-67.0_alpha1 too. |
Created attachment 562304 [details] example python script that crashes I'm getting a crash in glib/gtk+ with python. This is affecting other people as well, see comments in #651616 regarding a gajim update. I reproduced this to a very simple poc (see attachment) that just starts a trivial gtk example program and enables spell support. This is the top of the stack trace: #0 0x00007ffff705ad14 in g_main_context_prepare (context=context@entry=0x555555787810, priority=priority@entry=0x7fffffffcf50) at /tmp/portage/dev-libs/glib-2.58.2/work/glib-2.58.2/glib/gmain.c:3485 #1 0x00007ffff705b71b in g_main_context_iterate (context=0x555555787810, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /tmp/portage/dev-libs/glib-2.58.2/work/glib-2.58.2/glib/gmain.c:3900 What happens there is that some function pointer is passed around, though it seems from an invalid address. I was unable to figure out what's going on and hope others can help. I have asked other people if they can reproduce it, and I haven't found a non-Gentoo-user who sees the crash, so I believe it may be something Gentoo specific.