GNOME Bugzilla – Bug 676216
[gnome-boxes] SIGSEGV gvir_connection_find_storage_pool_by_name
Last modified: 2016-03-31 13:55:10 UTC
Description of problem: Program received signal SIGSEGV, Segmentation fault. gvir_connection_find_storage_pool_by_name (conn=0x0, name=name@entry=0x45885f "gnome-boxes") at libvirt-gobject-connection.c:1155 1155 GVirConnectionPrivate *priv = conn->priv; Version-Release number of selected component (if applicable): gnome-boxes-3.4.2-1.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. Create new box in Gnome Boxes. Actual results: Gnome Boxes crash Expected results: New box is created and booted. Backtrace: (gnome-boxes:13152): Clutter-WARNING **: No listener with the specified listener id 32 (gnome-boxes:13152): GLib-CRITICAL **: g_hash_table_remove_internal: assertion `hash_table != NULL' failed (gnome-boxes:13152): Clutter-WARNING **: Not able to remove listener with id 1 (gnome-boxes:13152): GLib-CRITICAL **: g_hash_table_size: assertion `hash_table != NULL' failed (gnome-boxes:13152): Clutter-WARNING **: The actor 'ClutterBox' is currently inside an allocation cycle; calling clutter_actor_queue_relayout() is not recommended Program received signal SIGSEGV, Segmentation fault. gvir_connection_find_storage_pool_by_name (conn=0x0, name=name@entry=0x45885f "gnome-boxes") at libvirt-gobject-connection.c:1155 1155 GVirConnectionPrivate *priv = conn->priv; Missing separate debuginfos, use: debuginfo-install spice-glib-0.12-2.fc17.x86_64 spice-gtk3-0.12-2.fc17.x86_64 (gdb) thread apply all bt full
+ Trace 230231
Thread 1 (Thread 0x7ffff7faba00 (LWP 13152))
Created attachment 214239 [details] Boxes backtrace
Thread 7 seems to be an async helper connecting to libvirt and which is not done yet (ie connection takes time), maybe from App::setup_libvirt. However, thread 1 (the main thread) seems to have moved on without waiting for the connection to be established, and we end up trying to use a connection while we haven't put anything yet in App::connections (this would explain the hash table warnings btw)
Error occured after overnight suspend. "killall libvirtd" didn't helped, reboot worked.
I think the main cause is a libvirtd hang that occurs sometimes after a suspend. I already got a backtrace for it but Daniel says thats not very useful and he is willing to debug it so if you could reproduce it somehow, contact danpb on IRC immediately and ask him what information he needs you to collect. I'll do the same when/if I reproduce it.
This may occur because libvirtd is hung, but it still looks like gnome-boxes code is racy and this needs to be fixed.
I can confirm I'm getting the same whenever I try to setup a box in Debian's gnome-boxes 3.4.1
Created attachment 214569 [details] [review] Wait for libvirt setup before creating VMs There is a possibility that we attempt to create VM before the async operation of creating libvirt connections is complete. When that happens, we end up making calls to null connection.
Review of attachment 214569 [details] [review]: we use to not start the UI until the default connection is established. I wonder if we should try to bring that back instead. Otherwise, I am affraid we may want to delay things here and there..
(In reply to comment #8) > Review of attachment 214569 [details] [review]: > > we use to not start the UI until the default connection is established. I > wonder if we should try to bring that back instead. Otherwise, I am affraid we > may want to delay things here and there.. Maybe but I recall there was a reason we changed this. This is one place we need to wait for connection for now so I'd say we should worry when we need to do this again in another part of the code.
*** Bug 676340 has been marked as a duplicate of this bug. ***
So whats the verdict?
Attachment 214569 [details] pushed as b3547ed - Wait for libvirt setup before creating VMs