GNOME Bugzilla – Bug 730022
Crash on empty source file
Last modified: 2016-03-31 13:22:07 UTC
Created attachment 276394 [details] gnome-boxes backtrace I'm using GNOME 3.10 on a Gentoo Linux system. I cannot start GNOME Boxes. If I try with command "gnome-boxes" on a terminal I get the following error message: $ gnome-boxes libGL error: dlopen /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: setupterm) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast Segmentation fault I already reported the libGL-related error to the Gentoo Bugzilla (see https://bugs.gentoo.org/show_bug.cgi?id=509272 and https://bugs.gentoo.org/show_bug.cgi?id=481316 for details). I recompiled gnome-boxes and glib with the "nostrip" FEATURES option and the "-ggdb" CFLAGS/CXXFLAGS, then ran gdb to obtain a backtrace. I'm attaching it to this bug report. Please also see https://bugzilla.gnome.org/show_bug.cgi?id=729345. ----- $ emerge -pv gnome-boxes These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] gnome-extra/gnome-boxes-3.10.2 USE="usbredir -smartcard" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB
Could you try `rm ~/.config/gnome-boxes/sources/*` before launching Boxes? Also, I assume you are not running Boxes as root (as thats not supported and is a bad idea anyway). For future reference, please inline the backtrace unless its extremely huge (in which case, you'll want to compress it before uploading here).
After removing the content of ~/.config/gnome-boxes/sources/ GNOME Boxes started. Thank you for the suggestion. I don't know why it crashed before. No, I was not running it as root. What do you mean by inline? Should I paste backtraces directly as comments and not as attached files?
(In reply to comment #2) > After removing the content of ~/.config/gnome-boxes/sources/ GNOME Boxes > started. Thank you for the suggestion. I don't know why it crashed before. Cool but with that suggestion, I completely lost the ability to track down the actual issue. :) > No, I was not running it as root. Good. Was just making sure. > What do you mean by inline? Should I paste backtraces directly as comments and > not as attached files? Yes. I'll resolve this as INVALID for now.
(In reply to comment #3) > (In reply to comment #2) > > After removing the content of ~/.config/gnome-boxes/sources/ GNOME Boxes > > started. Thank you for the suggestion. I don't know why it crashed before. > > Cool but with that suggestion, I completely lost the ability to track down the > actual issue. :) Fortunately I made a copy of the entire home partition the day before yesterday, as part of my backup plan. The only content of the .config/gnome-boxes/sources directory was an empty file called "QEMU Session". I hope this helps for reproducing this bug.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > After removing the content of ~/.config/gnome-boxes/sources/ GNOME Boxes > > > started. Thank you for the suggestion. I don't know why it crashed before. > > > > Cool but with that suggestion, I completely lost the ability to track down the > > actual issue. :) > > Fortunately I made a copy of the entire home partition the day before > yesterday, as part of my backup plan. The only content of the > .config/gnome-boxes/sources directory was an empty file called "QEMU Session". > I hope this helps for reproducing this bug. Yes, indeed it does. Boxes must have crashed before it could write contents to that file after creating it.
Created attachment 276458 [details] [review] app: Create qemu session source file if its empty Instead of only creating qemu session source file if it doesn't exist, also check if its empty and create it if thats the case. This fixes a crash that can happen if Boxes crashed on a previous run between the time the file is created and copied.
Fixed in 3.12 branch, will cherry-pick to master too. Attachment 276458 [details] pushed as 59ea141 - app: Create qemu session source file if its empty
Small variation on this bug: chmod 000 ~/.config/gnome-boxes/sources/QEMU\ Session $ LC_ALL=C jhbuild run gnome-boxes Gtk-Message: Failed to load module "canberra-gtk-module" (gnome-boxes:10719): Boxes-WARNING **: util.vala:222: Permission denied Missing or failing default libvirt connection
(In reply to comment #8) > Small variation on this bug: > chmod 000 ~/.config/gnome-boxes/sources/QEMU\ Session Isn't gvfs using a single syscall to create and setup permissions (open or create)? If so, can this issue actually hit user unless they fiddle with permissions manually? There is a warning on console so such advanced user has the info to rectify the issue easily.
Regardless of how this situation can happen, it's weird that we are able to create this file on demand (so Boxes knows what's in that file), but there are still situation where it won't startup because it cannot read that file.