Hey,
While testing Boxes, I've noticed that if I started a VM and then
let it in the background for a while, it usually crashed after
a while. When this happens, the backtrace is:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6671898 in gvir_event_handle_dispatch (source=0x7fffdc001f60,
condition=G_IO_IN, opaque=0x7fffdc0021a0) at libvirt-glib-event.c:135
135 (data->cb)(data->watch, data->fd, events, data->opaque);
(gdb) bt
#0 0x00007ffff6671898 in gvir_event_handle_dispatch (source=0x7fffdc001f60,
condition=G_IO_IN, opaque=0x7fffdc0021a0) at libvirt-glib-event.c:135
#1 0x00007ffff231dcb4 in g_io_unix_dispatch (source=0x40e34a0,
callback=0x7ffff66717d8 <gvir_event_handle_dispatch>,
user_data=0x7fffdc0021a0) at giounix.c:166
#2 0x00007ffff22cef15 in g_main_dispatch (context=0x7007f0) at gmain.c:2539
#3 0x00007ffff22cfbda in g_main_context_dispatch (context=0x7007f0)
at gmain.c:3075
#4 0x00007ffff22cfdbd in g_main_context_iterate (context=0x7007f0, block=1,
dispatch=1, self=0x15d3180) at gmain.c:3146
#5 0x00007ffff22cfe81 in g_main_context_iteration (context=0x7007f0,
may_block=1) at gmain.c:3207
#6 0x00007ffff2ad7e7c in g_application_run (application=0x70b890, argc=0,
argv=0x0) at gapplication.c:1607
#7 0x000000000041df98 in boxes_app_run (self=0x1527010) at app.c:1254
#8 0x0000000000450134 in _vala_main (args=0x7fffffffd708, args_length1=1)
at main.c:729
#9 0x000000000045019e in main (argc=1, argv=0x7fffffffd708) at main.c:740
and the corresponding gvir_event_handle structure is corrupted:
(gdb) p *data
$3 = {watch = 0, fd = 0, events = 1886417008, enabled = 1886417008,
channel = 0x7070707070707070, source = 1886417008, cb = 0x7070707070707070,
opaque = 0x7070707070707070, ff = 0x7ffff60cfba0 <virNetSocketEventFree>}
(gdb) p/x *data
$4 = {watch = 0x0, fd = 0x0, events = 0x70707070, enabled = 0x70707070,
channel = 0x7070707070707070, source = 0x70707070, cb = 0x7070707070707070,
opaque = 0x7070707070707070, ff = 0x7ffff60cfba0}
(I'm running with MALLOC_PERTURB_ set so the 0x70707070 pattern
indicates uninitialized memory).
Right before this happens, the libvirt-glib event debugging log has:
(gnome-boxes:29577): Libvirt.GLib-DEBUG: Remove handle 0x7fffdc0021a0 1 27
(gnome-boxes:29577): Libvirt.GLib-DEBUG: Update handle 0x7fffdc0021a0 1 27
1
(gnome-boxes:29577): Libvirt.GLib-DEBUG: Update for missing handle watch 1
(gnome-boxes:29577): Libvirt.GLib-DEBUG: Dispatch handler 0x7fffdc0021a0 0
0 1 0x7070707070707070
that is, libvirt removes a handle watch, and then updates this handle (in
other words, it calls virEventPollUpdateHandle after having called
virEventPollRemoveHandle on the same handle).
I don't know if it's legit for libvirt to do that, but we can make
libvirt-glib robust against this situation, which is what patch 5/5 does.
The first 3 patches are small cleanups, and 4/5 fixes a potential race
which I found while looking at this code.
Christophe
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list