Description of problem: Gaim crashes when trying to change Buddy Icon Version-Release number of selected component (if applicable): gaim-2.0.0-0.11.beta3.fc6 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.
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 mmap2(0xd65000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 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 mmap2(0xe81000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 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 mmap2(0xe88000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 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 _dbus_data_slot_allocator_alloc ) = 123 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(16459, 16459, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT +++ Process 16459 detached
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.
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 (gdb)
gaim upstream, J5 our dbus maintainer says that gaim requires changes in order to work properly. http://www.j5live.com/?p=246
We don't use gnome-vfs directly, something else (!gaim) should handle this.
*** Bug 201662 has been marked as a duplicate of this bug. ***
*** Bug 201971 has been marked as a duplicate of this bug. ***
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?
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.
<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: gdk_threads_init() dbus_g_threads_init() 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.
*** Bug 202138 has been marked as a duplicate of this bug. ***
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() first!" 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."
Hmm, doesn't this requirement kind of break API compatability?
<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. </rant> 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)
<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 elsewhere. 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.
Maybe gtk2 isn't the right component, but reassigning to the desktop team, because this is somewhere in the GNOME stack.
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. Ethan
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. Ethan
Warren, parking this bug on gtk is not going to get it fixed. It is not a gtk issue.
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.
that is dbus_threads_init not gtk_threads_init
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.
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?
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 appears. 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?
Sounds reasonable to me. Make sure you only call g_threads_init() if g_threads_supported() returns false otherwise glib will get angry.
Sounds good to me.
sounds like a solution
Created attachment 134172 [details] D-BUS thread initialization
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.
gboolean gaim_dbus_init(void) { gaim_dbus_init_ids(); 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?
You can simply add: if (g_thread_supported()) dbus_g_thread_init(); as the first two lines in gaim_dbus_init().
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 -lresolv 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
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.
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.
Mark, 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. http://fedoraproject.org/wiki/Core/Schedule 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?
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?
Yes.
So John actually already fixed d-bus up to support late thread initialization.
So this workaround in gaim is actually not needed?
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.
Fantastic! Thank you!
Any word if dbus-0.92 fixes this problem ?
Using gaim-2.0.0-0.11.beta3.fc6 dbus-0.92-1.fc6 I can open a file send dialog without gaim crashing.
Confirmed fixed by dbus-0.92. Closing.
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.
*** Bug 199815 has been marked as a duplicate of this bug. ***