Bug#758619: reportbug fails with Attempt to unlock mutex that was not locked

[Simon McVittie]

On Tue, 19 Aug 2014 at 12:08:39 +0200, Jan Binder wrote:
> reportbug just aborts with exit code 134 when it is started.
...
> > Attempt to unlock mutex that was not locked

I can't reproduce this: "reportbug reportbug" (with the default text-mode
UI) and "reportbug --ui=gtk2 reportbug" both seem to work fine here.

For those who can reproduce it, a backtrace with libgtk2.0-0-dbg,
libglib2.0-0-dbg and python-gtk2-dbg installed, using "thread apply all bt"
instead of just "bt", would be useful information.

It would also be useful if someone who can reproduce this could send the
output of these commands run in a terminal:

    reportbug --template libgtk2.0-0
    reportbug --template reportbug

which I think will work despite this bug.

On Tue, 19 Aug 2014 at 11:15:31 +0100, Sandro Tosi forwarded:
> > (gdb) bt
> > #0  0x00007ffff6f28407 in __GI_raise (sig=sig at entry=6) at
> > ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > #1  0x00007ffff6f297e8 in __GI_abort () at abort.c:89
> > #2  0x00007ffff2cdc85d in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #3  0x00007ffff19f4bbf in gtk_main () from
> > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
> > #4  0x00007ffff20a7d54 in ?? () from
> > /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/_gtk.so
> > #5  0x00007ffff4148a99 in ?? () from
> > /usr/lib/python2.7/lib-dynload/readline.x86_64-linux-gnu.so
> > #6  0x0000000000448d04 in PyOS_Readline ()

This looks more like a bug in Gtk2 or python-gtk2 than a GLib bug.
Frame 3 is in gtk_main(), frame 2 is in GLib which just issued a message
"Attempt to unlock mutex that was not locked", and frame 1 is abort():
this indicates that it was probably frame 3 (gtk_main()) that behaved
incorrectly.

The only way to address this bug from within GLib would be to remove the
check that says "unlocking a mutex that isn't locked is not allowed",
or reduce it from fatal to non-fatal but keep the spam to stderr.
If something is unlocking a mutex that isn't locked, that's a symptom
of a serious multi-threading bug somewhere (which could equally easily
manifest as a thread releasing a lock that it does not actually hold,
causing unsafe actions elsewhere), so I think it is correct that it is fatal
to make it as visible as possible.

I notice with some trepidation that /usr/share/pyshared/reportbug/ui/gtk2_ui.py
uses both Gtk and threads. I wonder whether the root cause of this bug
might be something like "the first use of Gtk2 happened to be from a
non-main thread"?

    S