Bug 201791 - Gaim dbus GNOME-VFS crash
Summary: Gaim dbus GNOME-VFS crash
Alias: None
Product: Fedora
Classification: Fedora
Component: libgnomeui   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
: 199815 201662 201971 202138 (view as bug list)
Depends On:
Blocks: FC6Blocker
TreeView+ depends on / blocked
Reported: 2006-08-08 20:37 UTC by Pete Graner
Modified: 2007-11-30 22:11 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-20 21:42:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
D-BUS thread initialization (1.99 KB, patch)
2006-08-14 22:00 UTC, Ethan Blanton
no flags Details | Diff
Patch for gaim-v2_0_0beta3 for real (2.00 KB, patch)
2006-08-15 05:31 UTC, Mark Doliner
no flags Details | Diff

Description Pete Graner 2006-08-08 20:37:50 UTC
Description of problem: Gaim crashes when trying to change Buddy Icon

Version-Release number of selected component (if applicable):

How reproducible: Always

Steps to Reproduce:
1. Start gaim
2. go to Accounts -> Add/Edit
3. Pick an account and select "Modify"
4. Click on the "Open" button to select a Buddy Icon.
5. Watch gaim go away.

Actual results: See step #5 above.

Expected results: Should have opened up a dialog to slect an image.

Additional info: I already have an image as my buddy icon and was looking to
change it when I discovered this.

Comment 1 Pete Graner 2006-08-08 20:42:48 UTC
I get this from strace... much snipped.

open("/etc/ld.so.cache", O_RDONLY)      = 24
fstat64(24, {st_mode=S_IFREG|0644, st_size=87608, ...}) = 0
mmap2(NULL, 87608, PROT_READ, MAP_PRIVATE, 24, 0) = 0xb56c3000
close(24)                               = 0
open("/lib/libattr.so.1", O_RDONLY)     = 24
read(24, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\274Q\000"..., 512) = 512
fstat64(24, {st_mode=S_IFREG|0755, st_size=15972, ...}) = 0
mmap2(NULL, 17248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 24, 0) = 0xd61000
24, 0x3) = 0xd65000
close(24)                               = 0
open("/lib/libacl.so.1", O_RDONLY)      = 24
read(24, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p#`\000"..., 512) = 512
fstat64(24, {st_mode=S_IFREG|0755, st_size=26028, ...}) = 0
mmap2(NULL, 27288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 24, 0) = 0xe7b000
24, 0x5) = 0xe81000
close(24)                               = 0
open("/usr/lib/libfam.so.0", O_RDONLY)  = 24
read(24, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@/\246\000"..., 512) = 512
fstat64(24, {st_mode=S_IFREG|0755, st_size=27864, ...}) = 0
mmap2(NULL, 25568, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 24, 0) = 0xe82000
24, 0x6) = 0xe88000
close(24)                               = 0
munmap(0xb56c3000, 87608)               = 0
setresuid32(-1, 500, -1)                = 0
setresgid32(-1, 500, -1)                = 0
write(2, "16459: assertion failed \"allocat"..., 12316459: assertion failed
"allocator->lock == mutex" file "dbus-dataslot.c" line 82 function
) = 123
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(16459, 16459, SIGABRT)           = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
Process 16459 detached

Comment 2 Warren Togami 2006-08-09 03:13:59 UTC
Due to the SIGABRT in common, I suspect this is related to Bug #201662.  There
is some issue with the GNOME library stack and possibly not a problem in gaim
itself.  It would be helpful to get a full gdb traceback after all relevant
-debuginfo is installed in gaim and the entire library call chain.

Comment 3 Pete Graner 2006-08-09 14:36:13 UTC
Response per comment #2

[pgraner@meatwad ~]$ gdb /usr/bin/gaim
GNU gdb Red Hat Linux (6.5-3.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/gaim 
[Thread debugging using libthread_db enabled]
[New Thread -1209141552 (LWP 18098)]
18098: assertion failed "allocator->lock == mutex" file "dbus-dataslot.c" line
82 function _dbus_data_slot_allocator_alloc

Program received signal SIGABRT, Aborted.
[Switching to Thread -1209141552 (LWP 18098)]
0xb7f01402 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7f01402 in __kernel_vsyscall ()
#1  0x00ca5cd9 in raise () from /lib/libc.so.6
#2  0x00ca7321 in abort () from /lib/libc.so.6
#3  0x001661b5 in dbus_malloc () from /lib/libdbus-1.so.3
#4  0x00150067 in dbus_watch_set_data () from /lib/libdbus-1.so.3
#5  0x0014c4c1 in dbus_watch_set_data () from /lib/libdbus-1.so.3
#6  0x0011e653 in dbus_connection_allocate_data_slot ()
   from /lib/libdbus-1.so.3
#7  0x0011c61f in dbus_bus_get_unix_user () from /lib/libdbus-1.so.3
#8  0x0011ca7b in dbus_bus_register () from /lib/libdbus-1.so.3
#9  0x0011d028 in dbus_bus_register () from /lib/libdbus-1.so.3
#10 0x06091a4e in gnome_vfs_daemon_set_current_connection ()
   from /usr/lib/libgnomevfs-2.so.0
#11 0x060ad1ba in gnome_vfs_volume_monitor_client_get_type ()
   from /usr/lib/libgnomevfs-2.so.0
#12 0x002616ba in g_type_create_instance () from /lib/libgobject-2.0.so.0
#13 0x00248f92 in g_object_set () from /lib/libgobject-2.0.so.0
#14 0x00246dfa in g_object_newv () from /lib/libgobject-2.0.so.0
#15 0x002478bf in g_object_new_valist () from /lib/libgobject-2.0.so.0
#16 0x00247a70 in g_object_new () from /lib/libgobject-2.0.so.0
#17 0x060ae35a in gnome_vfs_volume_monitor_emit_pre_unmount ()
   from /usr/lib/libgnomevfs-2.so.0
#18 0x060ae3ee in gnome_vfs_get_volume_monitor ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/libgnomevfs-2.so.0
#19 0x0267dd5d in fs_module_create ()
   from /usr/lib/gtk-2.0/2.10.0/filesystems/libgnome-vfs.so
#20 0x002616ba in g_type_create_instance () from /lib/libgobject-2.0.so.0
#21 0x00248f92 in g_object_set () from /lib/libgobject-2.0.so.0
#22 0x00246dfa in g_object_newv () from /lib/libgobject-2.0.so.0
#23 0x002478bf in g_object_new_valist () from /lib/libgobject-2.0.so.0
#24 0x00247a70 in g_object_new () from /lib/libgobject-2.0.so.0
#25 0x0267b2ac in gtk_file_system_gnome_vfs_new ()
   from /usr/lib/gtk-2.0/2.10.0/filesystems/libgnome-vfs.so
#26 0x0267b2e7 in fs_module_create ()
   from /usr/lib/gtk-2.0/2.10.0/filesystems/libgnome-vfs.so
#27 0x01072cad in gtk_file_selection_set_filename ()
   from /usr/lib/libgtk-x11-2.0.so.0
#28 0x01072e33 in gtk_file_selection_set_filename ()
   from /usr/lib/libgtk-x11-2.0.so.0
#29 0x01063ac4 in gtk_file_chooser_button_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#30 0x0024916c in g_object_set () from /lib/libgobject-2.0.so.0
#31 0x010673a1 in gtk_file_chooser_button_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#32 0x00246dfa in g_object_newv () from /lib/libgobject-2.0.so.0
#33 0x00247969 in g_object_new_valist () from /lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#34 0x00247a70 in g_object_new () from /lib/libgobject-2.0.so.0
#35 0x01059578 in gtk_file_chooser_button_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#36 0x0106b93c in gtk_file_chooser_widget_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#37 0x00246dfa in g_object_newv () from /lib/libgobject-2.0.so.0
#38 0x002478bf in g_object_new_valist () from /lib/libgobject-2.0.so.0
#39 0x00247a70 in g_object_new () from /lib/libgobject-2.0.so.0
#40 0x01067d4d in gtk_file_chooser_dialog_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#41 0x00246dfa in g_object_newv () from /lib/libgobject-2.0.so.0
#42 0x00247969 in g_object_new_valist () from /lib/libgobject-2.0.so.0
#43 0x00247a70 in g_object_new () from /lib/libgobject-2.0.so.0
#44 0x0106784e in gtk_file_chooser_dialog_get_type ()
   from /usr/lib/libgtk-x11-2.0.so.0
#45 0x010678fc in gtk_file_chooser_dialog_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#46 0x0092830a in icon_select_cb (button=0x8ff7c28, dialog=0x906b3b8)
    at gtkaccount.c:424
#47 0x0024f139 in g_cclosure_marshal_VOID__VOID ()
   from /lib/libgobject-2.0.so.0
#48 0x00241f0b in g_closure_invoke () from /lib/libgobject-2.0.so.0
#49 0x00252d73 in g_signal_override_class_closure ()
---Type <return> to continue, or q <return> to quit---
   from /lib/libgobject-2.0.so.0
#50 0x0025426f in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#51 0x00254429 in g_signal_emit () from /lib/libgobject-2.0.so.0
#52 0x00ff41b3 in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0
#53 0x00ff5dfe in gtk_button_set_alignment () from /usr/lib/libgtk-x11-2.0.so.0
#54 0x0024f139 in g_cclosure_marshal_VOID__VOID ()
   from /lib/libgobject-2.0.so.0
#55 0x002406f9 in g_value_set_static_boxed () from /lib/libgobject-2.0.so.0
#56 0x00241f0b in g_closure_invoke () from /lib/libgobject-2.0.so.0
#57 0x0025320a in g_signal_override_class_closure ()
   from /lib/libgobject-2.0.so.0
#58 0x0025426f in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#59 0x00254429 in g_signal_emit () from /lib/libgobject-2.0.so.0
#60 0x00ff4243 in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0
#61 0x00ff42a1 in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0
#62 0x010c38a0 in gtk_marshal_BOOLEAN__VOID ()
   from /usr/lib/libgtk-x11-2.0.so.0
#63 0x002406f9 in g_value_set_static_boxed () from /lib/libgobject-2.0.so.0
#64 0x00241f0b in g_closure_invoke () from /lib/libgobject-2.0.so.0
#65 0x002533c3 in g_signal_override_class_closure ()
   from /lib/libgobject-2.0.so.0
#66 0x00254037 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#67 0x00254429 in g_signal_emit () from /lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#68 0x011d6aa8 in gtk_widget_get_default_style ()
   from /usr/lib/libgtk-x11-2.0.so.0
#69 0x010bcd43 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#70 0x010bdf47 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#71 0x001cd0fa in gdk_add_client_message_filter ()
   from /usr/lib/libgdk-x11-2.0.so.0
#72 0x002aa342 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#73 0x002ad31f in g_main_context_check () from /lib/libglib-2.0.so.0
#74 0x002ad6c9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#75 0x010be3c4 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#76 0x0095f38a in main (argc=1, argv=0xbf893134) at gtkmain.c:765

Comment 4 Warren Togami 2006-08-09 18:08:09 UTC
gaim upstream, J5 our dbus maintainer says that gaim requires changes in order
to work properly.


Comment 5 Stu Tomlinson 2006-08-10 00:59:36 UTC
We don't use gnome-vfs directly, something else (!gaim) should handle this.

Comment 6 Warren Togami 2006-08-10 01:47:43 UTC
*** Bug 201662 has been marked as a duplicate of this bug. ***

Comment 7 Warren Togami 2006-08-10 01:48:05 UTC
*** Bug 201971 has been marked as a duplicate of this bug. ***

Comment 8 Warren Togami 2006-08-10 02:32:23 UTC
John, gaim doesn't think it should be gaim's problem because they don't use
GNOME-VFS directly.  Should this go somewhere else in the library stack?

Comment 9 Ray Strode [halfline] 2006-08-10 04:51:26 UTC
So a workaround for this crash is:

gconftool-2 --set /desktop/gnome/interface/file_chooser_backend --type string 'gtk+'

I could be way off, but I'm thinking right now that the easiest way to fix this
would be for gtk to initialize it's gtkfilesystem backend once at gtk_init time.

This doesn't address the problem of the backend xsetting getting changed to the
thread backend while the app is running though.  So maybe,
1) the gnome-vfs filesystem backend should fail if threads aren't already
initialized (and gtk+ should fallback to the unix one). 
2) if the user specified the gnome-vfs backend in gconf then gtk+ might want to
initialize threads in gtk_init. Doing this in a generic way might require new
module api, not sure.

All of this definitely needs more thought though.

Comment 10 John (J5) Palmieri 2006-08-10 15:23:47 UTC
<rant>Its the same old gaim, not my responsibility, I don't want to be a gnome
app, and don't want to take responsibility for the API's I use.</rant>

Now that that is out of my system (hint I've worked with the Gaim community
before).  There are two options here, 1) don't use D-Bus or 2) initalize
threading before you use D-Bus.  If every plugin and place where D-Bus is first
used does this then you should be covered.  This is part of the required use of
D-Bus since D-Bus is too low level to determine what threading system to use. 
It is an easy two liner:


And those can be called any number of times with no harm done.  Perhaps we
should just do this in a dbus_g_init() method in the glib bindings since
bindings are high level enough to do this, however it will be awhile before you
will be able to depend on that and just cuts down two lines to one.  I'll make
sure to add that in any case.

Comment 11 Warren Togami 2006-08-11 03:12:08 UTC
*** Bug 202138 has been marked as a duplicate of this bug. ***

Comment 12 Mark Doliner 2006-08-12 21:48:13 UTC
I kind of agree with Stu: since we don't use gnome-vfs directly I don't think we
should be responsible for this.

You're suggesting the following though process, which is a non sequitur: "I'm
about to call gtk_file_chooser_dialog_new(), I better call gdk_threads_init()

If you truly believe this should happen, I suggest adding a note to the
documentation for gtk_file_chooser_dialog_new() along the lines of: "Warning: If
the user of the application is running in the Gnome environment then you must
call either gnome_vfs_init() or gdk_threads_init() before using this."

Comment 13 Mark Doliner 2006-08-12 21:59:43 UTC
Hmm, doesn't this requirement kind of break API compatability?

Comment 14 Peter Lawler 2006-08-12 22:43:10 UTC
<rant>it's the same old (insert upstream person), not taking responsibility for
(insert library etc. here) brokenness.. same old (insert random q redhat engi)
making wild statements about what gaim is or isn't

gaim is NOT a gnome app. It's gtk. Let me repeat it so all the engis in redhat
can learn this.

gaim is NOT a gnome app. gaim is a gtk app.
gaim is NOT a gnome app. gaim is a gtk app.
gaim is NOT a gnome app. gaim is a gtk app.
gaim is NOT a gnome app. gaim is a gtk app.
gaim is NOT a gnome app. gaim is a gtk app.


Now I've got that out of my system... I agree with Mark's second para (I'll
humour him and agree to the typo too)

Comment 15 Stu Tomlinson 2006-08-13 17:28:11 UTC
<rant>Ranting is not helpful</rant>

I apologize if my comment came across as me being an arrogant Gaim developer,
but  I genuinely believe that this particular issue would be better handled

We also have to consider that the D-Bus support in Gaim is in core, not in the
Gtk UI, so we can't currently depend on a particular UI.

And I don't think there was any need for Comment #14 at all.

Comment 16 Warren Togami 2006-08-13 17:34:10 UTC
Maybe gtk2 isn't the right component, but reassigning to the desktop team,
because this is somewhere in the GNOME stack.

Comment 17 Ethan Blanton 2006-08-13 19:37:17 UTC
If thread initialization is a documented requirement for using the D-Bus [glib?]
API, then it sounds like Gaim is responsible for initializing glib for threads.
 If this is _not_ a documented requirement for using D-Bus, then it sounds like
it is either a) a D-Bus documentation bug, or b) a case of upstream library
maintainers passing the buck to applications and then <rant>ing about how
application programmers don't like to be slapped in the face with suprising
library requirements.

In either the first case or a) above, it should be fixed in Gaim and that's the
end of the story.  I have not yet consulted the D-Bus documentation.


Comment 18 Ethan Blanton 2006-08-13 23:59:17 UTC
After consulting the D-Bus documentation, this really isn't clear to me.  Said
documentation says only that dbus_g_threads_init MAY be called at most once and
MUST be called before any other D-Bus functions are called; I read that as the
usual initialization for possibly unused subsystems warning, and I suspect that
it is truly intended to not be called if threads are not in use.  It seems to me
that the problem here is that gnome vfs is popping up when we haven't asked for
it, and it uses threads.  We don't use threads, we don't *ask* for anything
which uses threads (though gstreamer may also bring this problem to light at
some point -- and gstreamer even has a legitimate case for using threads), but
we get them by way of gnome vfs.

It is pretty clear to me that it is *not* Gaim's fault, and that the _right_
place to fix this is not in Gaim.  ("Everyone just call g_thread_init everywhere
on the off chance that some random library you aren't aware of pops out of
nowhere and uses threads, okay?")  However, it looks like it's the most
expedient fix; snafus of this type often indicate major design flaws in the
initialization schemes underlying libraries, which aren't going to go away any
time soon.  It looks like the Gaim core should probably just call g_threads_init
and dbus_g_threads_init; other frontends (such as the Gtk+ frontend) will have
to call the appropriate thread initializers as well.  I would not make this
conditional on Gaim D-Bus usage, as this may very well pop up someplace else.

This is an unfortunate misdesign.


Comment 19 Matthias Clasen 2006-08-14 12:46:06 UTC
Warren, parking this bug on gtk is not going to get it fixed. It is not a gtk issue.

Comment 20 John (J5) Palmieri 2006-08-14 14:52:56 UTC
I'm also sorry for my rant.   It is not my issue responses gets me a little hot
and as one of the authors of the GAIM notification icon since the 1.x days it
brings up a bit of history.

To be a little more explanitory the issue is not Gnome-VFS.  Gnome-VFS simply
triggers the bug.  This is a gtk-threads/D-Bus issue.  As I noted above the
simple fix is to call gdk_threads_init, gtk_threads_init before you use D-Bus
which has always been a requirement of D-Bus in any case where threads could be
used.  Threads do have a minor performance hit associated with them if the
application is not using threads but not much.

The other fix which we may be able to do in D-Bus is change the semantics from
having to initalize threads early to having to initalize threads before the
second thread is started.  This would allow Gnome-VFS to safely initalize
threads.  There is a question whether or not this is safe to do and is feasable
within D-Bus so as of now it stands that as a rule you must initialize threads
early.  This is not an API or ABI change as it has always been like this in
D-Bus.  We are just now hitting the issue because D-Bus is starting to be
integrated in more complex code than it has been in the past. 

Comment 21 John (J5) Palmieri 2006-08-14 15:37:48 UTC
that is dbus_threads_init not gtk_threads_init

Comment 22 John (J5) Palmieri 2006-08-14 15:41:18 UTC
chalk up another one to need for caffeine in the morning.  While you can use
dbus_threads_init, using dbus_g_threads_init is much easier in a GLib environment.  

Comment 23 Ray Strode [halfline] 2006-08-14 15:57:10 UTC
So the question is, where does the fix need to go... I think we can see pretty
clearly that it's not gaim's fault.  Gaim has no way of anticipating that gtk+
is going to initialize dbus threads out from under it.  Still, apps work around
library bugs all the time, and I think it would be prudent for gaim to work
around this bug (until it's fixed) as well.

Now the question is, is the bug in dbus or gtk+?  dbus says that if you're going
to use threads at all, then you need initialize threads before you use dbus.  In
that respect, the gnome-vfs backend is broken.  By design it's not loaded when
the program starts, it can't know whether the program uses dbus, so it shouldn't
be using dbus with threads.  So how do we go forward...  

One approach would be to fix dbus to not have the restriction.  It could be
fixed up to support only having to call dbus_threads_init before starting the
second thread of a program.  That's the nicest fix.  

Another approach would be to fix the gnome-vfs backend so that by design it is
loaded when the program starts.  This could be done by making it double as a gtk
module that is loaded by another xsetting.  This fix should work, too, at the
cost of *always* initializing threads in every gtk+ app when using gnome.

I'd vote for lobbying for dbus to be enhanced to support this, but if they
aren't keen on it we'll have to opt for the second choice.

I'm moving this to libgnomeui (where the vfs backend lives).  But,

Warren can you build the workaround into gaim in rawhide until we can get this
fixed right?  What's upstreams opinion about working around things in the interim?

John, what's the odds we could get things improved in dbus?   If a patch landed
in front of you, would you take it?

Comment 24 Ethan Blanton 2006-08-14 19:01:54 UTC
j5: I understand that "it's not my issue" responses can be irritating, but in
the case (similar to this one) where it really _isn't_ the application
programmer's problem, it is likewise irritating to hear it from library
vendors/packagers/whoever.  The best approach is truly to find out where the
problem *really* is, as well as where the fix is best applied, and then weigh
the options.  I really feel that we have been doing so in this thread, and this
is the way the process Should Work.  In any case, apology accepted.

Ray: I think we, as Gaim programmers, are in accordance with your first
paragraph.  The only question is exactly how we will handle thread
initialization in general.  I will talk it over with the other Gaim developers
(at least a handful of whom are monitoring or have posted to this bug report),
but I think that the "best" solution (in light of the library misdesigns we're
dealing with) appears to be to call g_threads_init() for Gaim in all
circumstances, as well as dbus_g_threads_init() when dbus is compiled in.  We
will make the patch available to Warren (and our other distributors) when it

Does that sound like an appropriate approach to all involved?  I kind of hate to
take the threads hit (particularly given that at least several of us are
strongly in opposition to the inappropriate use of threads) and I would rather
see a real solution, but the effects in this case are not that great and the
hack isn't at all dirty.  Opinions?

Comment 25 Ray Strode [halfline] 2006-08-14 19:19:11 UTC
Sounds reasonable to me.  Make sure you only call g_threads_init() if
g_threads_supported() returns false otherwise glib will get angry.

Comment 26 Mark Doliner 2006-08-14 19:42:17 UTC
Sounds good to me.

Comment 27 John (J5) Palmieri 2006-08-14 19:50:03 UTC
sounds like a solution

Comment 28 Ethan Blanton 2006-08-14 22:00:45 UTC
Created attachment 134172 [details]
D-BUS thread initialization

Comment 29 Ethan Blanton 2006-08-14 22:02:18 UTC
Great.  The fix for this is revision 16759 on Gaim trunk, 16760 for the 2.0.0
branch.  The diff is attached.  Let us know if it doesn't solve the problem.

Comment 30 Warren Togami 2006-08-15 01:35:18 UTC
gboolean gaim_dbus_init(void)
    return gaim_dbus_dispatch_init() ;

This is what gaim_dbus_init looks like in gaim-2.0.0-beta3.  A bit different
from the diff attached here.  I'm guessing the diff is from HEAD while I really
want the patch from 2.0.0 branch?

Comment 31 Ethan Blanton 2006-08-15 01:46:11 UTC
You can simply add:

        if (g_thread_supported())

as the first two lines in gaim_dbus_init().

Comment 32 Warren Togami 2006-08-15 03:47:30 UTC
That applied against 2.0.0-beta3 fails build.  I have to sleep now, will work on
it again tomorrow.

/bin/sh ../libtool --silent --tag=CC --mode=link gcc  -g -O2 -g -pipe 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-all
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables   -o gaim -pie -export-dynamic account.o
accountopt.o blist.o buddyicon.o cipher.o cmds.o connection.o conversation.o
core.o debug.o desktopitem.o eventloop.o ft.o gaim_buffer.o idle.o imgstore.o
log.o mime.o network.o ntlm.o notify.o plugin.o pluginpref.o pounce.o prefix.o
prefs.o privacy.o proxy.o prpl.o request.o roomlist.o savedstatuses.o server.o
signals.o dnssrv.o status.o stringref.o stun.o sound.o sslconn.o upnp.o util.o
value.o xmlnode.o whiteboard.o dbus-server.o dbus-useful.o gtkblist.o
gtkcombobox.o gtkcelllayout.o gtkcellview.o gtkcellviewmenuitem.o gtkaccount.o
gtkcellrendererprogress.o gtkconn.o gtkconv.o gtkdebug.o gtkdialogs.o
gtkdnd-hints.o gtkeventloop.o gtkexpander.o gtkft.o gtkidle.o gtkimhtml.o
gtkimhtmltoolbar.o gtklog.o gtkmain.o gtkmenutray.o gtknotify.o gtkplugin.o
gtkpluginpref.o gtkprefs.o gtkprivacy.o gtkpounce.o gtkrequest.o gtkroomlist.o
gtksavedstatuses.o gtksession.o gtksound.o gtksourceiter.o gtkstatusbox.o
gtkstock.o gtkthemes.o gtkutils.o gtkwhiteboard.o -L/lib -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0
-lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -L/lib -ldbus-glib-1
-ldbus-1 -lglib-2.0   -L/usr/lib -lao -ldl -laudiofile -lm    -lSM -lICE -lX11
-lXext   -lXss -lSM -lICE  -L/lib -lgtkspell -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -lstartup-notification-1    -lnsl
gtkmain.o: In function `main':
/home/builder5/rpmbuild/BUILD/gaim-2.0.0beta3/src/gtkmain.c:652: undefined
reference to `g_thread_init'
collect2: ld returned 1 exit status

Comment 33 Mark Doliner 2006-08-15 05:31:22 UTC
Created attachment 134189 [details]
Patch for gaim-v2_0_0beta3 for real

Here ya go Warren, try this one.

Also, are you planning on shipping beta3 in FC6?  It might be better to ship
the current SVN of the v2_0_0 branch?  Maybe?  I don't know.

Comment 34 Ethan Blanton 2006-08-15 13:30:33 UTC
Actually, you'll have to re-run autogen.sh ... I hadn't thought of that, but
that'll be a problem for release tarballs.  You'll want to rerun it and supply a
configure diff as well, I guess.

Comment 35 Warren Togami 2006-08-15 13:58:09 UTC

The folks in #gaim last night warned me against using the v2_0_0 branch because
it is less stable than beta3.  I understand that beta3 is old at this point but
this doesn't leave us with any good options.

Would it be possible to stabilize v2_0_0 enough before September 5th so that we
may use anything newer in FC6?  Perhaps release a beta4?

Comment 36 Mark Doliner 2006-08-15 16:32:29 UTC
I'm not sure if we'll be releasing a beta4.  It's probably not a bad idea, since
we've made so many changes.  If 2.0.0 beta 3 goes into FC6, will you be able to
update it to 2.0.0 final after FC6 is released?

Comment 37 Warren Togami 2006-08-15 18:55:29 UTC

Comment 38 Ray Strode [halfline] 2006-08-18 18:45:44 UTC
So John actually already fixed d-bus up to support late thread initialization.

Comment 39 Warren Togami 2006-08-18 18:50:20 UTC
So this workaround in gaim is actually not needed?

Comment 40 John (J5) Palmieri 2006-08-18 18:59:25 UTC
I'm doing a release today.  For Fedora the fix should not be needed but other
distros might depending on what versions of components they ship.

Comment 41 Mark Doliner 2006-08-18 19:05:42 UTC
Fantastic!  Thank you!

Comment 42 Matthias Clasen 2006-08-20 21:22:03 UTC
Any word if dbus-0.92 fixes this problem ?

Comment 43 darrell pfeifer 2006-08-20 21:34:26 UTC


I can open a file send dialog without gaim crashing.

Comment 44 Warren Togami 2006-08-20 21:42:51 UTC
Confirmed fixed by dbus-0.92.  Closing.

Comment 45 Mark Doliner 2006-08-21 00:13:06 UTC
Excellent.  John, I really do appreciate you making those changes in d-bus. 
Thank you.

FYI we're considering taking out the thread init code we added.  It's causing
deadlocks related to our "Send To" menu.  We had a similar problem with drag and
drop that we fixed.  I'm a bit worried that we'll run into other unforseen
problems related to having threading enabled.

Our reasoning is that the window of people who will have a threaded gnome-vfs
and also dbus < 0.92 is pretty small.

Comment 46 Warren Togami 2006-08-26 21:49:54 UTC
*** Bug 199815 has been marked as a duplicate of this bug. ***

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