Comment 8 for bug 1425297

I was able to reproduce this bug after many, many reboots.

The relevant gdb trace is:

> Thread 2 (Thread 0xb1eff3c0 (LWP 2818)):
> #0 0xb69a84b0 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
> #1 0xb6b51112 in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
> #2 0xb6b3bd0c in g_once_init_enter () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
> #3 0xb6ec5e54 in g_dbus_proxy_get_type () from /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0
> #4 0xb6ed0b36 in ?? () from /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 1 (Thread 0xb6f4a000 (LWP 2715)):
> #0 0xb6d88554 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1 0xb6d861e4 in __lll_lock_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #2 0xb6d829a6 in pthread_mutex_lock () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #3 0xb6be514a in g_type_add_interface_static () from /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0
> #4 0xb6ec5ea4 in g_dbus_proxy_get_type () from /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0
> #5 0x000a5242 in accounts_service_sound_proxy_get_type ()
> #6 0x000a5722 in accounts_service_sound_proxy_new_for_bus ()
> #7 0x00099a1c in unity::indicator::datetime::Snap::Snap(std::shared_ptr<unity::indicator::notifications::Engine> const&, std::shared_ptr<unity::indicator::datetime::Settings const> const&) ()
> #8 0x0005d9da in main ()

This looks like a deadlock issue when a session's first call to g_dbus_proxy_get_type() occurs as two threads are calling it at the same time. This is a variation on sibling bug #1239710, which did the same thing for G_TYPE_DBUS_CONNECTION instead of G_TYPE_DBUS_PROXY, and we can work around it here the same way larsu did for the former in <https://code.launchpad.net/~larsu/indicator-datetime/glib-deadlock-workaround/+merge/191622>.

Upstream glib ticket is at https://bugzilla.gnome.org/show_bug.cgi?id=674885