Description of problem: Before the crash, virt-manager had been launched via sudo and running already for some time---I usually start it manually this way soon after logging in (since I am lazy to find out how to set permissions properly). At some point I launched yum update in a byobu (i.e. screen) session and detached from it. After few minutes, a message popped up complaining that the qemu: connection was broken. I dismissed the message and went to check out the virt-manager and indeed, my machines were not available. So I quit the virt-manager and launched it again, this time without sudo. That's when it crashed. I'm not sure if any of my machines were running, I haven't been using any of them today. The laptop had been suspended overnight. Version-Release number of selected component: virt-manager-1.0.0-3.fc20 Additional info: reporter: libreport-2.1.12 backtrace_rating: 4 cmdline: /usr/bin/python2 -tt /usr/share/virt-manager/virt-manager crash_function: g_settings_schema_get_value executable: /usr/bin/python2.7 kernel: 3.13.4-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 22482 Truncated backtrace: Thread no. 1 (10 frames) #2 g_settings_schema_get_value at gsettingsschema.c:640 #3 g_settings_schema_key_init at gsettingsschema.c:805 #4 g_settings_get_value at gsettings.c:1074 #5 ffi_call_unix64 at ../src/x86/unix64.S:76 #6 ffi_call at ../src/x86/ffi64.c:522 #7 g_callable_info_invoke at girepository/gicallableinfo.c:680 #8 g_function_info_invoke at girepository/gifunctioninfo.c:274 #9 _invoke_callable at pygi-invoke.c:64 #10 pygi_callable_info_invoke at pygi-invoke.c:652 #11 _wrap_g_callable_info_invoke at pygi-invoke.c:675 Potential duplicate: bug 958697
Created attachment 871419 [details] File: backtrace
Created attachment 871420 [details] File: cgroup
Created attachment 871421 [details] File: core_backtrace
Created attachment 871422 [details] File: dso_list
Created attachment 871423 [details] File: environ
Created attachment 871424 [details] File: limits
Created attachment 871425 [details] File: maps
Created attachment 871426 [details] File: open_fds
Created attachment 871427 [details] File: proc_pid_status
Created attachment 871428 [details] File: var_log_messages
Can you reproduce with virt-manager --debug and post the output here? I think this is a case of virt-manager trying to access an uninitialized gsettings key, and when that happens there's usually stderr output telling us what key is at fault.
We talked on IRC a bit, and the issue isn't reproducible now. So, closing. If the issue is reproducible in the future, please try and capture the --debug output as requested in Comment #11