Bug 849622 - Hang in virNetSocketEventFree
Hang in virNetSocketEventFree
Product: Virtualization Tools
Classification: Community
Component: libvirt-glib (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Libvirt Maintainers
Depends On:
  Show dependency treegraph
Reported: 2012-08-20 07:30 EDT by Zeeshan Ali
Modified: 2016-09-19 21:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-21 12:18:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Zeeshan Ali 2012-08-20 07:30:06 EDT
Description of problem:

I'm seeing Boxes hang when a VM shuts down/reboots. Backtrace suggests its a problem in libvirt:

__lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
136	2:	movl	%edx, %eax
Missing separate debuginfos, use: debuginfo-install glibc-2.15-54.fc17.x86_64
(gdb) bt
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1  0x0000003dadc09c8c in _L_lock_1024 () from /lib64/libpthread.so.0
#2  0x0000003dadc09c35 in __pthread_mutex_lock (mutex=0x7fefb4001a80) at pthread_mutex_lock.c:105
#3  0x00007fefcfad08c6 in g_mutex_lock (mutex=0x1b722f0) at gthread-posix.c:208
#4  0x00007fefd4a75cee in gvir_event_handle_remove (watch=1) at libvirt-glib-event.c:277
#5  0x00007fefd435a8da in virEventRemoveHandle (watch=1) at util/event.c:84
#6  0x00007fefd447cb12 in virNetSocketDispose (obj=0x7fefb4001fb0) at rpc/virnetsocket.c:730
#7  0x00007fefd437f63a in virObjectUnref (anyobj=0x7fefb4001fb0) at util/virobject.c:139
#8  0x00007fefd447e4c7 in virNetSocketEventFree (opaque=0x7fefb4001fb0) at rpc/virnetsocket.c:1325
#9  0x00007fefd4a75c78 in _event_handle_remove (data=0x7fefb4001a40) at libvirt-glib-event.c:262
#10 0x00007fefcfa84c99 in g_idle_dispatch (source=0x56ad490, callback=0x7fefd4a75c21 <_event_handle_remove>, 
    user_data=0x7fefb4001a40) at gmain.c:4797
#11 0x00007fefcfa82656 in g_main_dispatch (context=0x1b967d0) at gmain.c:2707
#12 0x00007fefcfa83206 in g_main_context_dispatch (context=0x1b967d0) at gmain.c:3211
#13 0x00007fefcfa833e9 in g_main_context_iterate (context=0x1b967d0, block=1, dispatch=1, self=0x1bc6840)
    at gmain.c:3282
#14 0x00007fefcfa834ad in g_main_context_iteration (context=0x1b967d0, may_block=1) at gmain.c:3343
#15 0x00007fefd0717020 in g_application_run (application=0x2955580, argc=0, argv=0x0) at gapplication.c:1607
#16 0x0000000000420ac6 in boxes_app_run (self=0x1b70200) at /extra-data/checkout/gnome/gnome-boxes/src/app.vala:159
#17 0x000000000045141b in _vala_main (args=0x7fff1157e378, args_length1=1)
    at /extra-data/checkout/gnome/gnome-boxes/src/main.vala:133
#18 0x0000000000451485 in main (argc=1, argv=0x7fff1157e378) at /extra-data/checkout/gnome/gnome-boxes/src/main.vala:86

Version-Release number of selected component (if applicable): git master (on commit 6d96fab9cf4fb85de4b923b787b99d20d2dd2539).

How reproducible: 5/10

Steps to Reproduce:
1. Create a new box in gnome-boxes against winxp installer
2. Wait for the installer to reboot after its first stage
Actual results:

gnome-boxes hangs.

Expected results:

gnome-boxes should not hang.
Comment 1 Daniel Berrange 2012-08-20 07:59:04 EDT
This is a flaw in libvirt-glib's event loop. _event_handle_remove must *not* hold the event loop lock while invoking the callback, otherwise it leads to this deadlock scenario
Comment 2 Daniel Berrange 2012-08-20 08:00:36 EDT
This bug was introduced in this commit

commit 924178f6b35735458b37d30303fe7bc753dde0b1
Author: Christophe Fergeau <cfergeau@redhat.com>
Date:   Wed Jun 20 11:04:25 2012 +0200

    mainloop: protect 'handles' and 'timeouts' against concurrent accesses

We just need to move the lock calls down to after the callback invocation
Comment 3 Daniel Berrange 2012-08-20 11:24:45 EDT
Please check whether this patch solves the hang


Note You need to log in before you can comment on or make changes to this bug.