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
