This is happening because DBus doesn't do locking by default. I presume this is for performance reasons. Luckily, the solution to this problem is very simple. Simply run dbus_thread_init_default() before you try accessing DBus.
#0 0xb4d58d29 in _dbus_watch_invalidate (watch=0x0) at dbus-watch.c:147
#1 0xb4d57066 in free_watches (transport=0x979c0d0) at dbus-transport-socket.c:82
#2 0xb4d57e7e in socket_disconnect (transport=0x979c0d0) at dbus-transport-socket.c:908
#3 0xb4d561e8 in _dbus_transport_disconnect (transport=0x979c0d0) at dbus-transport.c:494
#4 0xb4d56c68 in _dbus_transport_queue_messages (transport=0x979c0d0) at dbus-transport.c:1137
#5 0xb4d3dc24 in _dbus_connection_get_dispatch_status_unlocked (connection=0x979c4b0) at dbus-connection.c:3983
#6 0xb4d3b695 in check_for_reply_and_update_dispatch_unlocked (connection=0x979c4b0, pending=0xb3c00550) at dbus-connection.c:2235
#7 0xb4d3b883 in _dbus_connection_block_pending_call (pending=0xb3c00550) at dbus-connection.c:2337
#8 0xb4d501c1 in dbus_pending_call_block (pending=0xb3c00550) at dbus-pending-call.c:707
#9 0xb4d7aedf in dbus_g_proxy_end_call_internal (proxy=0x9776f90, call_id=30, error=0xb4d2d30c, first_arg_type=158972744, args=0xb4d2d2e4 "��Ҵ") at dbus-gproxy.c:2256
#10 0xb4d7b90e in dbus_g_proxy_call (proxy=0x9776f90, method=0xb4dca4bb "Get", error=0xb4d2d30c, first_arg_type=64) at dbus-gproxy.c:2584
DBus and Threads
06 March 2009
Sometimes you'll be using Dbus with threads and notice intermittent segfaults with stack traces like this;