This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 181992 - xchat crashes when clearlooks theme is used
xchat crashes when clearlooks theme is used
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xchat (Show other bugs)
5
All Linux
medium Severity high
: ---
: ---
Assigned To: Christopher Aillon
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-18 10:13 EST by Bryan O'Sullivan
Modified: 2007-11-30 17:11 EST (History)
8 users (show)

See Also:
Fixed In Version: 2.6.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-06 15:47:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bryan O'Sullivan 2006-02-18 10:13:30 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):

gtk2-engines 2.7.4-1.2

I'm using the version in Fedora Development.

How reproducible:

100%

Steps to Reproduce:
1. Select clearlooks as GNOME theme.
2. Run xchat.
3. Kaboom!
  
Actual results:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208383824 (LWP 2859)]
0x00193498 in strcmp () from /lib/libc.so.6
(gdb) bt
#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 ()
   from /usr/lib/libgtk-x11-2.0.so.0
#8  0x0049c676 in clearlooks_style_register_type ()
   from /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so
#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 ()
   from /usr/lib/libgtk-x11-2.0.so.0
#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 ()
   from /usr/lib/libgobject-2.0.so.0
#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 ()
   from /usr/lib/libgtk-x11-2.0.so.0
#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 ()
   from /usr/lib/libgdk-x11-2.0.so.0
#21 0x039c5a7a in gtk_container_check_resize ()
   from /usr/lib/libgtk-x11-2.0.so.0
#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 ?? ()

Expected results:

No crash :-)
Comment 1 Bryan O'Sullivan 2006-02-18 10:14:35 EST
BTW, my backtrace is not the same as the one for bug 168409, so please don't
immediately close this as a dup.
Comment 2 Rahul Sundaram 2006-02-20 06:31:53 EST

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
Comment 3 Pete Zaitcev 2006-02-23 14:09:46 EST
It looks that I'm getting the same thing (and not like bug 168409).
This started after a recent upgrade.

(gdb) where
#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 ()
   from /usr/lib/libgobject-2.0.so.0
#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 ()
   from /usr/lib/libgobject-2.0.so.0
#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 ()
   from /usr/lib/libgtk-x11-2.0.so.0
#17 0x42aac3eb in gtk_tooltips_force_window ()
   from /usr/lib/libgtk-x11-2.0.so.0
#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 ()
(gdb)

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
xchat-2.6.0-4
gtk2-engines-2.7.4-1.2
[zaitcev@lembas ~]$ 
Comment 4 Pete Zaitcev 2006-02-23 14:11:25 EST
Setting state to "assigned" - Rahul posted to fedora-devel-list that
his scripts were overzealous.
Comment 5 Kevin Kofler 2006-03-04 23:38:13 EST
See also: 
https://sourceforge.net/tracker/?func=detail&atid=100239&aid=1441105&group_id=239 
 
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). 
Comment 6 Bryan O'Sullivan 2006-03-05 00:13:46 EST
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.
Comment 7 Kevin Kofler 2006-03-05 00:50:15 EST
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 
issue). 
Comment 8 Matthias Clasen 2006-03-05 09:11:57 EST
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 
quark hashtable.
Comment 9 Matthias Clasen 2006-03-05 09:17:34 EST
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.
Comment 10 Matthias Clasen 2006-03-05 09:20:10 EST
As a quick test of this conjecture, can you see if running xchat without any
plugins helps ?
Comment 11 Pete Zaitcev 2006-03-05 13:09:45 EST
Mine seems to work without plugins.
Comment 12 Kevin Kofler 2006-03-13 07:59:05 EST
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? 
Comment 13 Kevin Kofler 2006-03-13 08:01:18 EST
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. 
Comment 14 Matthias Clasen 2006-03-13 08:12:02 EST
Well, that comment is wrong as far as the analysis is concerned, but
not unloading the module is a working workaround.
Comment 15 Kevin Kofler 2006-03-13 08:14:23 EST
Which comment is wrong? #7, #13 or both? 
Comment 16 Matthias Clasen 2006-03-13 08:17:02 EST
This one:

>because libdbus 
>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
Comment 17 Xavier Claessens 2006-03-15 04:17:50 EST
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:
http://lists.freedesktop.org/archives/dbus/2005-November/003750.html

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.
Comment 18 Matthias Clasen 2006-03-15 07:47:04 EST
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
Comment 19 FX 2006-07-02 16:47:32 EDT
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
lucky :)
Comment 20 Peter Zelezny 2006-07-13 05:30:12 EDT
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.
Comment 21 Kevin Kofler 2006-07-13 05:35:13 EDT
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 
way through?

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).
Comment 22 Matthew Miller 2007-04-06 15:36:42 EDT
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.]
Comment 23 Hans de Goede 2007-04-06 15:44:51 EDT
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.
Comment 24 Matthew Miller 2007-04-06 15:47:52 EDT
thanks!

Note You need to log in before you can comment on or make changes to this bug.