Bug 986768
| Summary: | virt-manager start failed by trap int3. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jincheng Miao <jmiao> | ||||
| Component: | gtk3 | Assignee: | Benjamin Otte <otte> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.0 | CC: | dyuan, gsun, mclasen, mkletzan, mzhan, tpelka, tzheng, vhumpa, xwei | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-11-19 08:12:47 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 776673 [details]
the coredump package of virt-manager
It is fairly reproducible on updated rhel7, however unreproducible with upstream packages and the same virt-manager. I suspect one of the underlying libs to cause the problem. I also don't remember having this problem with pre-0.10.0 packages, so either virt-manager changed since then or glib/gtk/etc. did. If you could try older virt-manager build (but newer than 0.9.x) with the other package versions kept and the same with the other libs while keeping newest virt-manager? If you would have a bit time to check this it would help a lot. Thanks, Martin I have some test on it.
The earliest available virt-manager used gtk3 is virt-manager-0.10.0-0.4.gitb68faac8.el7.
And there are test results:
virt-manager
0.10.0-0.4.gitb68faac8.el7 0.10.0-1.el7
glib2-2.36.0-1.el7.x86_64 failed failed
gtk3-3.8.1-1.el7.x86_64
libX11-1.5.0-3.el7.x86_64
glib2-2.36.3-2.el7.x86_64 failed failed
gtk3-3.8.2-1.el7.x86_64
libX11-1.5.0-3.el7.x86_64
glib2-2.36.3-2.el7.x86_64 failed failed
gtk3-3.8.2-2.el7.x86_64
libX11-1.5.0-3.el7.x86_64
glib2-2.36.3-2.el7.x86_64 failed failed
gtk3-3.8.2-2.el7.x86_64
libX11-1.5.99.902-1.el7.x86_64
BTW, it is not fairly reproducible. I reproduce it based on the steps: 1. reboot the computer A 2. ssh <computer A> -X 3. virt-manager # repeat on it until crash happened :( (usually 5-6 times). Even though possible, I highly doubt that this is virt-manager's problem as it doesn't persist through multiple distributions I've tried to reproduce it on. The reason I tried multiple distros is that virt-manager-0.10.0-1 is pure upsteam package and I am sure this is the code that hasn't changed. I'm thus reassigning this BZ to gtk3 because that is the most related place I can think of. Let me know if I can help with this issue anyhow. This bug is pretty unclear. There is an error message about a missing file: Jul 19 10:59:17 localhost abrt[13188]: Can't open file '/etc/os-release': No such file or directory what is the guest OS here, what is the host ? On the other hand, the stacktrace clearly shows an X error occurring. Please reproduce this error with GDK_SYNCHRONIZE=1 and get a stacktrace that shows which X call is actually failing, and with what error. Please see if you can reproduce this problem with ssh -Y instead of ssh -X too. Hi Matthias, The previous OS is lost, and I try to reproduce this bug on latest rhel7 os. # rpm -q glib2 gtk3 libX11 libX11-common glib2-2.36.3-5.el7.x86_64 gtk3-3.8.8-5.el7.x86_64 libX11-1.6.0-2.el7.x86_64 libX11-common-1.6.0-2.el7.noarch Seems this bug can not be reproduced even add GDK_SYNCHRONIZE=1: # ssh root.xx.xx -Y # GDK_SYNCHRONIZE=1 virt-manager --debug --no-conn-autostart quote: " There is an error message about a missing file: Jul 19 10:59:17 localhost abrt[13188]: Can't open file '/etc/os-release': No such file or directory " This is abrt reported, after the INT3 happened, seems not important. *** Bug 1083435 has been marked as a duplicate of this bug. *** 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-2015-2116.html |
Description of problem: I start virt-manager from remote machine (ssh -X), virt-manager meet a int3 instruction during start. Version-Release number of selected component (if applicable): virt-manager-0.10.0-1.el7.noarch libvirt-1.1.0-1.el7.x86_64 glib2-2.36.0-1.el7.x86_64 gtk3-3.8.1-1.el7.x86_64 libX11-1.5.0-3.el7.x86_64 libX11-common-1.5.0-3.el7.noarch How reproducible: <10% Steps to Reproduce: 1. connect remote machine # ssh root.XX.XX -X 2. start virt-manager # virt-manager --no-conn-autostart 3. sometimes failed here, check /var/log/messages # vim /var/log/messages Jul 19 10:59:17 localhost kernel: [218158.013255] traps: virt-manager[13182] trap int3 ip:3807c4ef4d sp:7fffb9974d20 error:0 Jul 19 10:59:17 localhost abrt[13188]: Can't open file '/etc/os-release': No such file or directory Jul 19 10:59:18 localhost abrt[13188]: Saved core dump of pid 13182 (/usr/bin/python2.7) to /var/tmp/abrt/ccpp-2013-07-19-10:59:17-13182 (67125248 bytes) Jul 19 10:59:18 localhost abrtd: Directory 'ccpp-2013-07-19-10:59:17-13182' creation detected Jul 19 10:59:19 localhost abrtd: Generating core_backtrace Jul 19 10:59:19 localhost abrtd: Generating backtrace Jul 19 10:59:19 localhost abrtd: Backtrace is generated, 37856 bytes Jul 19 10:59:20 localhost abrtd: Core backtrace is generated and saved, 10886 bytes the backtrace is: 0x4ef4d g_logv /lib64/libglib-2.0.so.0 0x4f132 g_log /lib64/libglib-2.0.so.0 0x446f0 _gdk_x11_display_error_event /lib64/libgdk-3.so.0 0x4f091 gdk_x_error /lib64/libgdk-3.so.0 0x45526 _XError /lib64/libX11.so.6 0x42771 handle_error /lib64/libX11.so.6 0x427b5 handle_response /lib64/libX11.so.6 0x433a8 _XReply /lib64/libX11.so.6 0x2e1e1 XInternAtoms /lib64/libX11.so.6 0x4f976 _gdk_x11_precache_atoms /lib64/libgdk-3.so.0 0x4bb74 _gdk_x11_window_register_dnd /lib64/libgdk-3.so.0 0xf988 g_closure_invoke /lib64/libgobject-2.0.so.0 0x2099d signal_emit_unlocked_R /lib64/libgobject-2.0.so.0 0x28789 g_signal_emit_valist /lib64/libgobject-2.0.so.0 0x289d2 g_signal_emit /lib64/libgobject-2.0.so.0 0x2b6336 gtk_widget_realize /lib64/libgtk-3.so.0 0x2b6630 gtk_widget_map /lib64/libgtk-3.so.0 0xb4c6a gtk_box_forall /lib64/libgtk-3.so.0 0xf81bf gtk_container_map /lib64/libgtk-3.so.0 0xfb2f _g_closure_invoke_va /lib64/libgobject-2.0.so.0 0x27ce7 g_signal_emit_valist /lib64/libgobject-2.0.so.0 0x289d2 g_signal_emit /lib64/libgobject-2.0.so.0 0x2b65f9 gtk_widget_map /lib64/libgtk-3.so.0 0xb4c6a gtk_box_forall /lib64/libgtk-3.so.0 0xf81bf gtk_container_map /lib64/libgtk-3.so.0 0xfb2f _g_closure_invoke_va /lib64/libgobject-2.0.so.0 0x27ce7 g_signal_emit_valist /lib64/libgobject-2.0.so.0 0x289d2 g_signal_emit /lib64/libgobject-2.0.so.0 0x2b65f9 gtk_widget_map /lib64/libgtk-3.so.0 0x2c7b00 gtk_window_map /lib64/libgtk-3.so.0 0xfbb7 _g_closure_invoke_va /lib64/libgobject-2.0.so.0 0x27ce7 g_signal_emit_valist /lib64/libgobject-2.0.so.0 0x289d2 g_signal_emit /lib64/libgobject-2.0.so.0 0x2b65f9 gtk_widget_map /lib64/libgtk-3.so.0 0x2c0571 gtk_window_show /lib64/libgtk-3.so.0 0xf988 g_closure_invoke /lib64/libgobject-2.0.so.0 0x201a7 signal_emit_unlocked_R /lib64/libgobject-2.0.so.0 0x28789 g_signal_emit_valist /lib64/libgobject-2.0.so.0 0x289d2 g_signal_emit /lib64/libgobject-2.0.so.0 0x2b485c gtk_widget_show /lib64/libgtk-3.so.0 0x5dd8 ffi_call_unix64 /lib64/libffi.so.6 0x57e0 ffi_call /lib64/libffi.so.6 0xaa54 g_callable_info_invoke /lib64/libgirepository-1.0.so.1 0xbdbb g_function_info_invoke /lib64/libgirepository-1.0.so.1 0x13e8a pygi_callable_info_invoke /usr/lib64/python2.7/site-packages/gi/_gi.so 0xdd21a PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdec6d PyEval_EvalCodeEx /lib64/libpython2.7.so.1.0 0xdd759 PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdd7fc PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdd7fc PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdd7fc PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdec6d PyEval_EvalCodeEx /lib64/libpython2.7.so.1.0 0x6dc90 - /lib64/libpython2.7.so.1.0 0x49dd3 PyObject_Call /lib64/libpython2.7.so.1.0 0x58555 - /lib64/libpython2.7.so.1.0 0x49dd3 PyObject_Call /lib64/libpython2.7.so.1.0 0xd8ae7 PyEval_CallObjectWithKeywords /lib64/libpython2.7.so.1.0 0x124f6 pygi_signal_closure_marshal /usr/lib64/python2.7/site-packages/gi/_gi.so 0xf988 g_closure_invoke /lib64/libgobject-2.0.so.0 0x2099d signal_emit_unlocked_R /lib64/libgobject-2.0.so.0 0x28789 g_signal_emit_valist /lib64/libgobject-2.0.so.0 0x289d2 g_signal_emit /lib64/libgobject-2.0.so.0 0x96388 g_application_real_local_command_line /lib64/libgio-2.0.so.0 0x964cc g_application_run /lib64/libgio-2.0.so.0 0x5dd8 ffi_call_unix64 /lib64/libffi.so.6 0x57e0 ffi_call /lib64/libffi.so.6 0xaa54 g_callable_info_invoke /lib64/libgirepository-1.0.so.1 0xbdbb g_function_info_invoke /lib64/libgirepository-1.0.so.1 0x13e8a pygi_callable_info_invoke /usr/lib64/python2.7/site-packages/gi/_gi.so 0xdd21a PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdec6d PyEval_EvalCodeEx /lib64/libpython2.7.so.1.0 0xdd759 PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdec6d PyEval_EvalCodeEx /lib64/libpython2.7.so.1.0 0xdd759 PyEval_EvalFrameEx /lib64/libpython2.7.so.1.0 0xdec6d PyEval_EvalCodeEx /lib64/libpython2.7.so.1.0 0xded72 PyEval_EvalCode /lib64/libpython2.7.so.1.0 0xf786f - /lib64/libpython2.7.so.1.0 0xf898e PyRun_FileExFlags /lib64/libpython2.7.so.1.0 0xf9af9 PyRun_SimpleFileExFlags /lib64/libpython2.7.so.1.0 0x10a59f Py_Main /lib64/libpython2.7.so.1.0 0x21b75 __libc_start_main /lib64/libc.so.6 0x721 _start /usr/bin/python2.7 The above backtrace is from core_backtrace abrt generated, and I trip some words for seeing clearly. In the source of glib-2.36.3, the function g_logv contains: if (!(test_level & G_LOG_FLAG_RECURSION)) G_BREAKPOINT (); else abort (); Abviously, the condition is true. So virt-manager execute int3. So far, I don't know this problem belongs to virt-manager or glib2 or others. Actual results: start unsuccessfully Expected results: start successfully Additional info: The attachment is coredump package.