Hide Forgot
Description of problem: virt-manager crashes after clicking the loging button Version-Release number of selected component (if applicable): virt-manager-1.2.1-8.el7.noarch How reproducible: 100% Steps to Reproduce: 1. launch "virt-manager" 2. Open hardware details and click "display spice" device and Set a password for it. 3. Start the guest. 4. Check the "Save this password in your keyring" option and type the password. 5. Close the vm window and double click the vm to open the vm window again, check the password is remembered but the "Save this password in your keyring" option is not checked. 6. Clear the password string and click login, nothing happenes. 7. Close the vm window and open it again, type the correct password and then click login button. 8. Repeat step6 and step7 several times, after about 5 times, the virt-manager crashes. Actual results: bug1: After step 5, the "Save this password in your keyring" option is unchecked unexpectedly. bug2: After step8, virt-manager crashes. Expected results: After step5, the "Save this password in your keyring" option should still be checked. After step8, virt-manager should not crash. Additional info: Please see virt-manager --debug log and abrt log in attachments.
Created attachment 1118386 [details] virt-manager --debug log
Created attachment 1118387 [details] abrt log
Hi, so at first, please file one bug for each issue, never add more than one issue into a single bug. The first issue is probably virt-manager bug and I'll look into it. The second issue is a crash where coredump is produced. Virt-manager itself cannot crash as it's pure python code, there could be only unhandled exception related to virt-manager code. If coredump is produced by running virt-manager, the package to blame is python or any other module used by virt-manager, which can be deducted from the backtrace. In this case it's probably python or spice.
(In reply to Pavel Hrdina from comment #4) > Hi, so at first, please file one bug for each issue, never add more than one > issue into a single bug. > > The first issue is probably virt-manager bug and I'll look into it. I filed bug 1302175 for the first issue. Bug 1302175 - The "Save this password in your keyring" option is unchecked unexpectedly > > The second issue is a crash where coredump is produced. Virt-manager itself > cannot crash as it's pure python code, there could be only unhandled > exception related to virt-manager code. If coredump is produced by running > virt-manager, the package to blame is python or any other module used by > virt-manager, which can be deducted from the backtrace. In this case it's > probably python or spice.
Based on comment 4 moving to spice-gtk for further investigation.
These uncaught exceptions in the log do not look good: [Tue, 26 Jan 2016 13:53:57 virt-manager 5167] DEBUG (cli:241) Uncaught exception: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/console.py", line 691, in _viewer_add_display self._refresh_resizeguest_from_settings() File "/usr/share/virt-manager/virtManager/console.py", line 351, in _refresh_resizeguest_from_settings elif not self._viewer.console_has_agent(): File "/usr/share/virt-manager/virtManager/viewers.py", line 249, in console_has_agent return self._has_agent() File "/usr/share/virt-manager/virtManager/viewers.py", line 658, in _has_agent return self._main_channel.get_property("agent-connected") TypeError: object at 0x3893d70 of type MainChannel is not initialized Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/console.py", line 691, in _viewer_add_display self._refresh_resizeguest_from_settings() File "/usr/share/virt-manager/virtManager/console.py", line 351, in _refresh_resizeguest_from_settings elif not self._viewer.console_has_agent(): File "/usr/share/virt-manager/virtManager/viewers.py", line 249, in console_has_agent return self._has_agent() File "/usr/share/virt-manager/virtManager/viewers.py", line 658, in _has_agent return self._main_channel.get_property("agent-connected") TypeError: object at 0x3893d70 of type MainChannel is not initialized If virt-manager is misusing spice-gtk C API (for example by passing it uninitialized memory), then it may crash. I don't know how to get a C or python backtrace for the code which caused the segmentation fault out of the abrt log. Could you add one of these to the bug?
The thing is, that virt-manager uses only python code, which means it uses python binding of spice-gtk C API. There is no such thing like uninitialized memory in python. Yes, we should probably do a better work in handling exceptions and I'll look into it, still, it shouldn't crash.
If you misuse spice-gtk API from Python, I'm fairly sure you can get it to crash. This bug has nothing to rule that out, and has some worrying python assertions which could hint that. At the same time, it's missing a C backtrace, or anything that could give us info about what's going on on the spice-gtk side (SPICE_DEBUG=1 virt-manager -d might help too)
Created attachment 1118774 [details] SPICE_DEBUG=1 virt-manager --debug log
Could you extract a backtrace from the coredump you have, or attach gdb to the running running virt-manager process, trigger a crash and get the backtrace from there?
Created attachment 1119072 [details] gdb backtrace log
The C backtrace at the time of the crash matches the python backtrace mentioned in comment #7: /usr/share/virt-manager/virtManager/viewers.py, line 658, in _has_agent /usr/share/virt-manager/virtManager/viewers.py, line 249, in console_has_agent /usr/share/virt-manager/virtManager/console.py, line 351, in _refresh_resizeguest_from_settings /usr/share/virt-manager/virtManager/console.py, line 691, in _viewer_add_display
fixed upstream by commits: ff25f3eacb1776a754147cd57c76882392382030 6b475802d78f2a4f2110738cb360b496dc85336c
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2229.html