valgrind (helgrind) on linux (sid amd64 chroot on wheezy amd64) didn't turn up anything that looked too useful. There were a number of diagnostics of this general form:
==12158== Lock at 0x603E5C0 was first observed ==12158== at 0x4C2EB32: pthread_mutex_init (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158== by 0x6A644F6: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A64594: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A647C8: g_mutex_lock (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x67BDA97: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A2757: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A4210: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A485B: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x6568A48: ??? (in /usr/lib/libgirepository-1.0.so.1.0.0) ==12158== by 0x6568F58: g_irepository_get_default (in /usr/lib/libgirepository-1.0.so.1.0.0) ==12158== by 0x633BEEF: _wrap_g_irepository_get_default (pygi-repository.c:72) ==12158== by 0x4B73E9: PyEval_EvalFrameEx (ceval.c:4005) ==12158== ==12158== Possible data race during read of size 4 at 0xD2C3910 by thread #3 ==12158== Locks held: none ==12158== at 0x6A64BA9: g_private_set (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A48EF7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x4C2E93D: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158== by 0x4E3DE0D: start_thread (pthread_create.c:311) ==12158== ==12158== This conflicts with a previous write of size 4 by thread #1 ==12158== Locks held: 1, at address 0x603E5C0 ==12158== at 0x67BD9E0: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A2757: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A4210: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A485B: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0xC718EAA: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2) ==12158== by 0x67BD93E: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A2757: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x67A4210: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== ==12158== Address 0xD2C3910 is 0 bytes inside a block of size 4 alloc'd ==12158== at 0x4C2BEAB: malloc (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158== by 0x6A6443D: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A64BA8: g_private_set (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A48EF7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x4C2E93D: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158== by 0x4E3DE0D: start_thread (pthread_create.c:311) I don't know enough about the structure of glib to speculate as to whether this is expected or indicative of bad behavior. and some of this general form: ==12158== Thread #1: pthread_cond_destroy: destruction of unknown cond var ==12158== at 0x4C2D342: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so) ==12158== by 0x6A64A0B: g_cond_clear (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x73670E8: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3600.1) ==12158== by 0x67A2577: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.1) ==12158== by 0x6A21DD7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A22356: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A24F6F: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A25267: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0x6A256D9: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.1) ==12158== by 0xC8213B4: gtk_main (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.400.2) ==12158== by 0x7648E27: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1) ==12158== by 0x764878F: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1) which may be a known bug in valgrind: https://bugs.kde.org/show_bug.cgi?id=307082 If it's not a valgrind false positive, I do believe pthread_cond_destroy on a cond variable already in an undefined state is undefined behavior (but I couldn't find chapter and verse, just e.g., reports like this one http://sourceware.org/bugzilla/show_bug.cgi?id=1473 where responders to the bug say it is undefined behavior). On the other hand, doing this in a simple standalone program on kfreebsd-amd64 didn't provoke any misbehavior out of the gate..
signature.asc
Description: Digital signature
