GNOME Bugzilla – Bug 307639
DBUS notification fails when running on remote display
Last modified: 2013-09-10 14:04:09 UTC
The Evolution Mail component doesn't work over NX (FreeNX) remote display or SSH tunnel if "Generate a D-BUS message if new mail arrives" is checked, although the other components (Mail, Calendar, Contacts) seem to mostly work (with the occasional crash). Mail opens and fully displays, then crashes. The output on the terminal is as follows. See my comments in <<...>>: -------- [luke@oasis ~]$ evolution --force-shutdown Shutting down evolution-data-server-1.2 (Evolution Calendar file and webcal backend / Evolution Addressbook file backend) Shutting down evolution-alarm-notify (Evolution Calendar alarm notification service) [luke@oasis ~]$ evolution -c mail es menu class init adding hook target 'source' Failed to connect to the D-BUS daemon: Unable to determine the address of the message bus 9069: arguments to dbus_connection_get_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 4478. This is normally a bug in some application using the D-BUS library. 9069: arguments to dbus_connection_set_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 4442. This is normally a bug in some application using the D-BUS library. ** ERROR **: Not enough memory to set up DBusConnection for use with GLib aborting... <<CRASH! -- see backtrace below>> <<After Bug-Buddy exits:>> aborting... Variable "msg" is not available. Variable "msg" is not available. Variable "msg" is not available. Variable "message" is not available. [luke@oasis ~]$ evolution --force-shutdown Shutting down evolution-data-server-1.2 (Evolution Calendar file and webcal backend / Evolution Addressbook file backend) Shutting down evolution-alarm-notify (Evolution Calendar alarm notification service) [luke@oasis ~]$ evolution -c calendar es menu class init adding hook target 'source' calendar-gui-Message: ********* the state is 2 calendar-gui-Message: ********* the state is 2 calendar-gui-Message: ********* the state in ok is 3 calendar-gui-Message: ********* the state in ok is 3 calendar-gui-Message: ********* the state in ok is 3 calendar-gui-Message: ********* the state in ok is 3 <<Everything apparently works fine; I then close the Calendar Window>> (evolution:9219): GLib-CRITICAL **: g_hash_table_foreach: assertion `hash_table != NULL' failed (evolution:9219): GLib-CRITICAL **: g_hash_table_destroy: assertion `hash_table != NULL' failed (evolution:9219): GLib-CRITICAL **: g_source_remove: assertion `tag > 0' failed [luke@oasis ~]$ ----------------- Here's a backtrace of the crash labeled "<CRASH! -- see backtrace below>". Bug-Buddy seems to clip the backtrace partway through: ----------------- Backtrace was generated from '/usr/bin/evolution' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209121088 (LWP 9069)] [New Thread -1232868432 (LWP 9095)] [New Thread -1222378576 (LWP 9094)] [New Thread -1211503696 (LWP 9074)] 0x00bee402 in ?? ()
+ Trace 60989
Thread 1 (Thread -1209121088 (LWP 9069))
--------------------- I can only assume VNC etc. would also be affected? I'm guessing the "connection=0x0" and "bus = (DBusConnection *) 0x0" parts are bad... Probably related to the messages on the terminal of: Failed to connect to the D-BUS daemon: Unable to determine the address of the message bus 9979: arguments to dbus_connection_get_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 4478. This is normally a bug in some application using the D-BUS library. ** ERROR **: Not enough memory to set up DBusConnection for use with GLib aborting...
duplicate of 274329, or perhaps a bug in dbus outside our scope?
It looks like dbus returns a NULL connection due to failure to connect. There are really two issues: 1. evolution should handle a NULL connection gracefully instead of imploding 2. figure out how to get a non-NULL connection in this context; which I would guess means forwarding the DBUS_SESSION_BUS_ADDRESS variable over ssh and ensuring the session bus is listening on tcp (theoretically already possible/working today). Another option involving new code is to set up a helper process that gets/sets the dbus address as an X property on the root window.
Must be fixed as a part of #274329 fix. However we are not going to ensure notification to work over remote connection. Evolution as such should work fine after the fix.
*** Bug 344662 has been marked as a duplicate of this bug. ***