Comment 8 for bug 724874

Over the weekend this has been happening fairly reliably within the first ~10 minutes of usage; (just attach gdb after you login and leave it running):

  Thread 1 (Thread 0xb76eb880 (LWP 2697)):
#0 0x0805bbfe in ?? ()
#1 0x008c5088 in g_cclosure_marshal_VOID__OBJECT () from /usr/lib/libgobject-2.0.so.0
#2 0x008a8352 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#3 0x008bb048 in ?? () from /usr/lib/libgobject-2.0.so.0
#4 0x008c3b29 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#5 0x008c3cc2 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#6 0x00c075ca in ?? () from /usr/lib/libwnck-1.so.22
#7 0x00c07c78 in ?? () from /usr/lib/libwnck-1.so.22
#8 0x003ff451 in ?? () from /lib/libglib-2.0.so.0
#9 0x00403c08 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#10 0x004043d0 in ?? () from /lib/libglib-2.0.so.0
#11 0x00404a93 in g_main_loop_run () from /lib/libglib-2.0.so.0
#12 0x00d5ca49 in IA__gtk_main () at /build/buildd/gtk+2.0-2.24.1/gtk/gtkmain.c:1255
#13 0x0804f580 in main ()

Running strings on the resulting gcore (yes, a bit basic, but I walked up and down the stack with "print *(char **)($esp-N)" manually), it might be:

  window-decorator:2697): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

since I found some of these component strings in the history of the stack (or it could be completely the wrong thing).