Re: [Qemu-devel] [PATCH 0/3] another round of qemu-char fixes

[Paolo Bonzini]

Il 18/04/2013 08:14, Gerd Hoffmann ha scritto:
> Thread 1 (Thread 0x7f9038188980 (LWP 27849)):
> ---Type <return> to continue, or q <return> to quit---
> #0  __lll_lock_wait () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
> #1  0x00007f90366a9388 in _L_lock_854 () from /lib64/libpthread.so.0
> #2  0x00007f90366a9257 in __pthread_mutex_lock (mutex=0x7f903abb1538) at
> pthread_mutex_lock.c:61
> #3  0x00007f9037903c37 in ?? () from /lib64/libglib-2.0.so.0
> #4  0x00007f90383c5d96 in io_watch_poll_finalize (source=<value
> optimized out>)
>     at /home/kraxel/projects/qemu/qemu-char.c:648

Hmm, this seems to be recursive locking.  It sounded unlikely, but then
googling for "glib gsource finalize unlock" led to this:

https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/887946

and this:

https://mail.gnome.org/archives/commits-list/2010-November/msg01816.html

and this:

https://bugzilla.gnome.org/show_bug.cgi?id=586432
https://bugzilla.gnome.org/show_bug.cgi?id=626702

Comment 6 of the latter bug says that finalize-inside-finalize is in
fact broken without this fix.  If this is RHEL6, you or Amit should file
a bug.

Paolo