Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 986768 - virt-manager start failed by trap int3.
Summary: virt-manager start failed by trap int3.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gtk3
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Benjamin Otte
QA Contact: Desktop QE
URL:
Whiteboard:
: 1083435 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-22 03:41 UTC by Jincheng Miao
Modified: 2017-11-13 10:49 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 08:12:47 UTC
Target Upstream Version:


Attachments (Terms of Use)
the coredump package of virt-manager (deleted)
2013-07-22 03:47 UTC, Jincheng Miao
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2116 normal SHIPPED_LIVE GTK+ bug fix and enhancement update 2015-11-19 08:39:32 UTC

Description Jincheng Miao 2013-07-22 03:41:22 UTC
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-22 03:47:38 UTC
Created attachment 776673 [details]
the coredump package of virt-manager

Comment 3 Martin Kletzander 2013-07-22 11:53:20 UTC
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 09:07:15 UTC
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 09:12:46 UTC
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 13:44:51 UTC
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 21:56:36 UTC
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-11 03:42:00 UTC
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 09:09:43 UTC
*** Bug 1083435 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2015-11-19 08:12:47 UTC
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.