Bug#671785: Workaround for kFreeBSD crash in reportbug

[Jeff Epler]

On Sun, Dec 30, 2012 at 05:34:10PM -0800, Christoph Egger wrote:
> > However, I still believe that the problem is either in python-gtk2 or
> > python-gtk2's FAQ advice on how to use gtk.gdk.threads_init().
> 
>   Can you be a bit more verbose about that? Also the FAQ might well be
> right and what we are seeing yet another bug in kfreebsd's pthread
> implementation.

My diagnosis that this is a pygtk bug rather than a kfreebsd bug
basically boils down to the fact that on linux, helgrind is giving a
diagnostic at the very place that kfreebsd is crashing.

Basically, after gdk_enable_threads(), any gtk call must be made with
the global lock held (gdk_threads_enter()).  In the case of gtk_main(),
it very soon calls gtk_threads_leave(), which is the spot where a
not-locked pthread mutex is unlocked.

That being the case, I suspect that the pygtk faq item is just omitting
the gtk.gdk.threads_enter() call before gtk_main for the sake of brevity
(but maybe because the error passes silently on Linux).  But whether that
is the case or not, pygtk really can't impose the additional requirement
on users of raw_input() that they have to manipulate a gdk lock before
the call; whatever it's doing had better be transparent to users of
raw_input.

However, on reading the glibc and posix manpages on
pthread_mutex_unlock, it should simply return nonzero and set errno to
EPERM in the case of unlocking a not-locked mutex, so it is probably
equally sensible to pursue this as a bug in the pthreads implementation
in debian kfreebsd's userspace... Unfortunately, I've failed to distill
what I think gtk is doing into a simple program that segfaults on
kfreebsd.

Jeff