nautilus segfaults in libunique

["Matthias Clasen" <matthias clasen gmail com>]

Hey, I'm seeing nautilus segfault when running 'nautilus /some/path'
on the commandline.
This is with nautilus 2.25.2 and unique 1.0.4

valgrind says:

==18672== Invalid free() / delete / delete[]
==18672==    at 0x400590A: free (vg_replace_malloc.c:323)
==18672==    by 0x6699DB5: g_free (gmem.c:190)
==18672==    by 0x2307D8: unique_message_data_free (uniquemessage.c:123)
==18672==    by 0x232A43: unique_factory_dbus_send_message
(uniquefactory-dbus.c:79)
==18672==    by 0x232B4F:
dbus_glib_marshal_uniquebackend_BOOLEAN__STRING_BOXED_UINT_POINTER_POINTER
(uniquebackend-bindings.h:98)
==18672==    by 0x3AB5D9: gobject_message_function (dbus-gobject.c:1284)
==18672==    by 0x43F764: (within /lib/libdbus-1.so.3.4.0)
==18672==    by 0x4311E3: dbus_connection_dispatch (in /lib/libdbus-1.so.3.4.0)
==18672==    by 0x3A810C: message_queue_dispatch (dbus-gmain.c:101)
==18672==    by 0x66916D7: g_main_context_dispatch (gmain.c:1814)
==18672==    by 0x6694D82: g_main_context_iterate (gmain.c:2448)
==18672==    by 0x66952A1: g_main_loop_run (gmain.c:2656)
==18672==  Address 0x77c0ec8 is 0 bytes inside a block of size 14 free'd
==18672==    at 0x400590A: free (vg_replace_malloc.c:323)
==18672==    by 0x6699DB5: g_free (gmem.c:190)
==18672==    by 0x2307D8: unique_message_data_free (uniquemessage.c:123)
==18672==    by 0x783AFA: boxed_proxy_value_free (gboxed.c:288)
==18672==    by 0x7AA917: g_value_unset (gvalue.c:276)
==18672==    by 0x79F35D: g_signal_emit_valist (gsignal.c:3006)
==18672==    by 0x79F7E5: g_signal_emit (gsignal.c:3034)
==18672==    by 0x22EA90: unique_app_emit_message_received (uniqueapp.c:713)
==18672==    by 0x232A39: unique_factory_dbus_send_message
(uniquefactory-dbus.c:78)
==18672==    by 0x232B4F:
dbus_glib_marshal_uniquebackend_BOOLEAN__STRING_BOXED_UINT_POINTER_POINTER
(uniquebackend-bindings.h:98)
==18672==    by 0x3AB5D9: gobject_message_function (dbus-gobject.c:1284)
==18672==    by 0x43F764: (within /lib/libdbus-1.so.3.4.0)

I haven't tracked this down, but it looks like something is forgetting
to call unique_message_data_copy(), or forgetting to copy the
startup_id ?