Comment 7 for bug 886467

Simply log each leak as a separate bug, putting the stack of the leak in the bug description. For example:

==9167== 5,062,678 (2,251,200 direct, 2,811,478 indirect) bytes in 56,280 blocks are definitely lost in loss record 19,601 of 19,602
==9167== at 0x4C293CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9167== by 0x66AD632: g_malloc (gmem.c:164)
==9167== by 0x66C23B6: g_slice_alloc (gslice.c:842)
==9167== by 0x66E09F9: g_variant_alloc (gvariant-core.c:475)
==9167== by 0x66E0AD2: g_variant_new_from_buffer (gvariant-core.c:509)
==9167== by 0x66DA87E: g_variant_new_from_trusted (gvariant.c:320)
==9167== by 0x91329D0: parse_value_from_blob (gdbusmessage.c:1219)
==9167== by 0x9132BBA: parse_value_from_blob (gdbusmessage.c:1446)
==9167== by 0x913437D: g_dbus_message_new_from_blob (gdbusmessage.c:1800)
==9167== by 0x913F718: _g_dbus_worker_do_read_cb (gdbusprivate.c:713)
==9167== by 0x90E6C16: g_simple_async_result_complete (gsimpleasyncresult.c:749)
==9167== by 0x90E6D28: complete_in_idle_cb (gsimpleasyncresult.c:761)
==9167== by 0x66A6A0C: g_main_context_dispatch (gmain.c:2425)
==9167== by 0x66A7207: g_main_context_iterate.isra.21 (gmain.c:3073)
==9167== by 0x66A7741: g_main_loop_run (gmain.c:3281)
==9167== by 0x913D5C5: gdbus_shared_thread_func (gdbusprivate.c:276)
==9167== by 0x66CC265: g_thread_create_proxy (gthread.c:1962)
==9167== by 0x6B68EFB: start_thread (pthread_create.c:304)
==9167== by 0x77FE89C: clone (clone.S:112)
==9167==

Then we can investigate each one separately and have a realistic chance of being able to fully resolve some of them. Maybe just start with those that say "definitely lost" :)

Longer runs are usually helpful, but in the case of unity I think it has so many leaks that we're already overwhelmed with data.