Bug 849622 - Hang in virNetSocketEventFree
Summary: Hang in virNetSocketEventFree
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt-glib
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-20 11:30 UTC by Zeeshan Ali
Modified: 2016-09-20 01:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-21 16:18:13 UTC
Embargoed:


Attachments (Terms of Use)

Description Zeeshan Ali 2012-08-20 11:30:06 UTC
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 Berrangé 2012-08-20 11:59:04 UTC
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 Berrangé 2012-08-20 12:00:36 UTC
This bug was introduced in this commit

commit 924178f6b35735458b37d30303fe7bc753dde0b1
Author: Christophe Fergeau <cfergeau>
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 Berrangé 2012-08-20 15:24:45 UTC
Please check whether this patch solves the hang

https://www.redhat.com/archives/libvir-list/2012-August/msg01345.html


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