Bug 986768 - virt-manager start failed by trap int3.
virt-manager start failed by trap int3.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gtk3 (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Benjamin Otte
Desktop QE
:
: 1083435 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-21 23:41 EDT by Jincheng Miao
Modified: 2015-11-19 03:12 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 03:12:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the coredump package of virt-manager (5.19 MB, application/x-gzip)
2013-07-21 23:47 EDT, Jincheng Miao
no flags Details

  None (edit)
Description Jincheng Miao 2013-07-21 23:41:22 EDT
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.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.
Comment 1 Jincheng Miao 2013-07-21 23:47:38 EDT
Created attachment 776673 [details]
the coredump package of virt-manager
Comment 3 Martin Kletzander 2013-07-22 07:53:20 EDT
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
Comment 4 Jincheng Miao 2013-07-23 05:07:15 EDT
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
Comment 5 Jincheng Miao 2013-07-23 05:12:46 EDT
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).
Comment 6 Martin Kletzander 2013-07-23 09:44:51 EDT
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.
Comment 7 Matthias Clasen 2014-03-10 17:56:36 EDT
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.
Comment 8 Jincheng Miao 2014-03-10 23:42:00 EDT
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.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.
Comment 9 Giuseppe Scrivano 2014-04-03 05:09:43 EDT
*** Bug 1083435 has been marked as a duplicate of this bug. ***
Comment 16 errata-xmlrpc 2015-11-19 03:12:47 EST
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

Note You need to log in before you can comment on or make changes to this bug.