Bug#707733: pygobject: FTBFS on kfreebsd

[Jeff Epler]

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..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20130515/d31ed67d/attachment-0001.pgp>