Description of problem: When an user is logged in without owning the "console" and runs pidgin, dbus code kills pidgin. This has not happened until some very recent dbus(?) update. Version-Release number of selected component (if applicable): dbus-1.2.4-1.fc9.x86_64 How reproducible: Always. Steps to Reproduce: 1. su otheruser 2. pidgin& 3. Type a message and press enter to send it. Actual results: pidgin windows disappears. pidgin process returns exit code 1. (Message is thankfully sent). Expected results: pidgin does not get killed after sending the message. Additional info: This is a showstopper. My SO and I cannot have own copies of pidgin running at the same time any more. The _exit() function is reached with following stack: (gdb) where #0 0x0000003ccd6a66c0 in _exit () from /lib64/libc.so.6 #1 0x00000031cca2a1f9 in _dbus_exit (code=<value optimized out>) at dbus-sysdeps-unix.c:2566 #2 0x00000031cca0deda in _dbus_connection_update_dispatch_status_and_unlock ( connection=<value optimized out>, new_status=<value optimized out>) at dbus-connection.c:4059 #3 0x00000031cca0fed7 in _dbus_connection_send_and_unlock ( connection=<value optimized out>, message=<value optimized out>, client_serial=<value optimized out>) at dbus-connection.c:2027 #4 0x00000031cca09e82 in dbus_bus_remove_match ( connection=<value optimized out>, rule=<value optimized out>, error=<value optimized out>) at dbus-bus.c:1532 #5 0x00000033d6010225 in dbus_g_proxy_manager_unregister ( manager=<value optimized out>, proxy=<value optimized out>) at dbus-gproxy.c:1055 #6 0x00000033d6011e0c in dbus_g_proxy_dispose (object=<value optimized out>) at dbus-gproxy.c:1460 #7 0x00000033ce40dac0 in g_object_run_dispose () from /lib64/libgobject-2.0.so.0 #8 0x00000033d6012150 in dbus_g_proxy_manager_filter ( connection=<value optimized out>, message=<value optimized out>, user_data=<value optimized out>) at dbus-gproxy.c:1493 #9 0x00000031cca0ef7b in dbus_connection_dispatch ( connection=<value optimized out>) at dbus-connection.c:4406 #10 0x00000033d6009715 in message_queue_dispatch ( source=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at dbus-gmain.c:101 #11 0x00000033ce03742b in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #12 0x00000033ce03ac0d in ?? () from /lib64/libglib-2.0.so.0 #13 0x00000033ce03b13d in g_main_loop_run () from /lib64/libglib-2.0.so.0 #14 0x00000033d1583db0 in IA__gtk_main () at gtkmain.c:1163 #15 0x000000000048424b in main (argc=1, argv=0x7fffb1d62198) at gtkmain.c:888
I hate to intrude, but is there any more effective method of fixing bugs than reporting them here?
Most likely a bug in Pidgin, which shouldn't fail to run if D-Bus isn't available. My guess is a missing call to dbus_connection_set_exit_on_disconnect().
Pidgin does not fail to run if D-Bus is unavailable. We also already have a call to dbus_connection_set_exit_on_disconnect().
There is one point to be stressed: pidgin does start when d-bus is unavailable, that is correct. However, pidgin process exits(1) when you try to send a message (you open a window, type a text, and press enter) - as described in the original report.
(In reply to comment #4) > There is one point to be stressed: pidgin does start when d-bus is unavailable, > that is correct. You haven't actually tested that though. If you explicitly prevent pidgin from finding the session bus I expect this forced exit would stop. You could achieve that by using "su - otheruser" (instead of "su otheruser"), or by unsetting the DBUS_SESSION_BUS_ADDRESS environment variable before launching pidgin. I'm not sure how to proceed in debugging this exit though. could you get a debug log from pidgin (from running "pidgin -d > debug.log"), and also let us know what plugins you have loaded? It might also be worth disabling sounds and see if it still exits when you send a message.
I remember however distinctly a message saying "Unable to get session bus: Did not receive a reply.". I am not going to question whether this means that the session bus was unavailable or it made itself and its services unavailable... My SO has switched to another IM program since there was no response to this report. It appears however that pidgin does not quit any more in such circumstances though.
It sounds like you are saying you are unwilling to debug the issue as requested. Reopen if you do so.
It sounds like you did not read the last sentence of my comment: the pidgin does not quit any more, I cannot reproduce the problem any more, there is nothing to debug.