Red Hat Bugzilla – Bug 181992
xchat crashes when clearlooks theme is used
Last modified: 2007-11-30 17:11:24 EST
Description of problem:
This is similar to bug 168409, but I wanted to file it separately so you'd know
how many apps were affected.
xchat crashes inside clearlooks code if the clearlooks theme is enabled. Since
clearlooks is the default theme for FC5, this means xchat always crashes unless
you switch to a different theme.
Version-Release number of selected component (if applicable):
I'm using the version in Fedora Development.
Steps to Reproduce:
1. Select clearlooks as GNOME theme.
2. Run xchat.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208383824 (LWP 2859)]
0x00193498 in strcmp () from /lib/libc.so.6
#0 0x00193498 in strcmp () from /lib/libc.so.6
#1 0x002e663b in g_str_equal () from /usr/lib/libglib-2.0.so.0
#2 0x002c168e in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0
#3 0x002ba5b7 in g_quark_try_string () from /usr/lib/libglib-2.0.so.0
#4 0x0028b3c7 in g_type_from_name () from /usr/lib/libgobject-2.0.so.0
#5 0x0028b6eb in g_type_from_name () from /usr/lib/libgobject-2.0.so.0
#6 0x00293631 in g_type_register_static () from /usr/lib/libgobject-2.0.so.0
#7 0x039c3bb0 in gtk_combo_box_entry_get_type ()
#8 0x0049c676 in clearlooks_style_register_type ()
#9 0x03a9f559 in gtk_paint_shadow () from /usr/lib/libgtk-x11-2.0.so.0
#10 0x039e59dc in gtk_entry_new () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x03a512f3 in gtk_marshal_BOOLEAN__VOID ()
#12 0x002726a5 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#13 0x00273dba in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#14 0x00285369 in g_signal_override_class_closure ()
#15 0x00285fcb in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#16 0x002863a8 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#17 0x03b2e430 in gtk_widget_get_default_style ()
#18 0x03a4cb02 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#19 0x038abbbf in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0
#20 0x038abd66 in gdk_window_process_all_updates ()
#21 0x039c5a7a in gtk_container_check_resize ()
#22 0x002cb0be in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#23 0x002cc7e9 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#24 0x002cf58d in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#25 0x002cf8be in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#26 0x03a4cd3c in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x0805d24b in ?? ()
#28 0x0809da32 in xchat_plugingui_remove ()
#29 0x0013f6b4 in __libc_start_main () from /lib/libc.so.6
#30 0x08053dd1 in ?? ()
No crash :-)
BTW, my backtrace is not the same as the one for bug 168409, so please don't
immediately close this as a dup.
These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks
It looks that I'm getting the same thing (and not like bug 168409).
This started after a recent upgrade.
#0 0x42446988 in strcmp () from /lib/libc.so.6
#1 0x426a9a04 in g_str_equal () from /usr/lib/libglib-2.0.so.0
#2 0x426825b6 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0
#3 0x4267adb1 in g_quark_try_string () from /usr/lib/libglib-2.0.so.0
#4 0x42732c29 in g_type_from_name () from /usr/lib/libgobject-2.0.so.0
#5 0x42732f80 in g_type_from_name () from /usr/lib/libgobject-2.0.so.0
#6 0x42737fd6 in g_type_register_static () from /usr/lib/libgobject-2.0.so.0
#7 0x42a252e5 in gtk_plug_get_type () from /usr/lib/libgtk-x11-2.0.so.0
#8 0x42b00bf5 in gtk_window_new () from /usr/lib/libgtk-x11-2.0.so.0
#9 0x427277b9 in g_cclosure_marshal_VOID__VOID ()
#10 0x427187d9 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#11 0x42719f9d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#12 0x4272c64a in g_signal_override_class_closure ()
#13 0x4272d623 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#14 0x4272d8c9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#15 0x42af1698 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x42aac019 in gtk_tooltips_force_window ()
#17 0x42aac3eb in gtk_tooltips_force_window ()
#18 0x4268e836 in g_source_get_current_time () from /usr/lib/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#19 0x4268e11d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0x426913af in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#21 0x42691759 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#22 0x429fb724 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#23 0x0805d24b in fe_main () at fe-gtk.c:277
#24 0x0809da32 in main (argc=Cannot access memory at address 0xb54247f7
) at xchat.c:1012
#25 0x423f27a4 in __libc_start_main () from /lib/libc.so.6
#26 0x08053dd1 in _start ()
The question is, why does xchat alone fail? This probably has to be
classified as an xchat problem. I'm adding Chris to cc:. Matthias does
not seem to be interested anyway.
[zaitcev@lembas ~]$ rpm -q xchat gtk2-engines
Setting state to "assigned" - Rahul posted to fedora-devel-list that
his scripts were overzealous.
To sum up: the upstream 2.6.1 RPM reportedly doesn't have this bug (even on
FC5t3), so I assume this means:
* either 2.6.1 fixes this (but the author doesn't know what could have fixed
it, so that's rather unlikely),
* or the Rawhide toolchain is miscompiling something (the upstream build is
compiled on FC4).
Whoa there. The clearlooks crash shows every appearance of being completely
unrelated to the crash I reported at sf.net. There's not one significant piece
of the two backtraces in common, as far as I can tell.
Now it's possible that rawhide gcc is miscompiling random bits of gtk code that
are at the root of these apparently otherwise unrelated problems. But I
wouldn't hold my breath.
I'm not so sure they're unrelated: in both cases, the top of the backtrace
matches: it's g_type_register_static which is trying to do a hash table lookup,
which is trying to do a string comparison and crashes. If (warning: wild guess
follows) an invalid pointer made its way into the hash table, then this would
explain a crash with that backtrace sooner or later, as soon as the offending
pointer is hit (which may well be sooner here and later for you, and the
apparently offending call to g_type_register_static may well come from
somewhere completely different in both cases, but it would still be the same
I'd assume that xchat maybe loads a module which uses g_quark_from_static_string.
If that module gets unloaded later, you end up with an invalid pointer in the
Quickly looking through the xchat code, I see the
dbus plugin use G_DEFINE_TYPE. If that module ever gets unloaded,
you'll see the problem I described.
As a quick test of this conjecture, can you see if running xchat without any
plugins helps ?
Mine seems to work without plugins.
Upstream says this is fixed in 2.6.1 (and yes, I still think this is the same
issue as the upstream bug I referenced, see my analysis in comment #7), so can
we please have an upgrade?
For reference, here's the comment from zed (the upstream author) on the
upstream bug tracker:
>Looks like a 2.6.0 issue, so this report is out of date.
>Unloading the dbus plugin caused crashes, because libdbus
>has no cleanup routines and leaves unloaded strings/types in
>glib's hash tables. In 2.6.1 we solved this by never
>unloading the plugin, even if the DBUS fails to initialize.
>P.S. you shouldn't be disabling the DBUS, Gnome needs it.
Well, that comment is wrong as far as the analysis is concerned, but
not unloading the module is a working workaround.
Which comment is wrong? #7, #13 or both?
>has no cleanup routines and leaves unloaded strings/types in
>glib's hash tables
The problem really is the use of G_DEFINE_TYPE in the plugin itself
The use of G_DEFINE_TYPE is necessary, dbus plugin can't work without that.
You can see more problems I posted on the DBUS mailing list:
I really think it's a DBUS-glib limitation. A solution is to make a python
plugin instead, or using low level DBUS to avoid using glib interface.
Nope, G_DEFINE_TYPE is _convenience_ api, so its use is never essential.
What you need to use is g_type_module_register_type(). Unfortunately,
we don't have a convenience macro like G_DEFINE_TYPE for (un)loadable types
yet, I'll try to add one in glib 2.12
It seems nobody's taking care of this any more... rendering xchat effectively
unusable in Fedora Core 5. In my case, the segfault happens only ofter the first
click (right click on the main window, or click on the menubar), so perhaps I'm
I'm not involved in fedora in any way, just as a happy user, but I would suggest
someone package up 2.6.1+ and it's solved. xchat-2.6.4 (with the two patches in
http://xchat.org/files/source/2.6/patches/) in FC6-t2 would be even better.
I'd say just package the latest even for FC5, version upgrades aren't generally
seen as a problem around here (just look at both central components like the
kernel, KDE or GNOME and all the programs in Extras), and library
soname/API/ABI changes aren't an issue for X-Chat either, so why not go all the
But even 2.6.1 would be better than nothing (though I'm not personally seeing
the 2.6.0 crashes, maybe because I'm running KDE and not GNOME).
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.
[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]
If I read the comments above, this got fixed in xchat 2.6.1, currently devel has
2.6.6 so I think this can be closed.