RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 872633 - Vdagent stops when first resizing a window
Summary: Vdagent stops when first resizing a window
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-vdagent
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Alon Levy
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 842355 881827
TreeView+ depends on / blocked
 
Reported: 2012-11-02 16:00 UTC by Tomas Jamrisko
Modified: 2013-07-03 12:12 UTC (History)
9 users (show)

Fixed In Version: spice-vdagent-0.12.0-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:23:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2013:0311 0 normal SHIPPED_LIVE spice-vdagent enhancement update 2013-02-20 20:35:19 UTC

Description Tomas Jamrisko 2012-11-02 16:00:35 UTC
Description of problem:
user process of vdagent stops when resizing remote-viewer window -- happens only on first resize, after logging in. It's working fine after manually restaring the agent

Version-Release number of selected component (if applicable):
spice-vdagent-0.12.0-2.el6.x86_64
xorg-x11-drv-qxl-0.1.0-2.el6.x86_64

How reproducible:
80% (never encountered this before, so this can be just a fluke) 

Steps to Reproduce:
1. connect to a VM using remote-viewer
    options of the VM were: 
     -spice port=<port>,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 <image>
2. Login as a user
3. Maximize the window
4. Try resizing the window once again
  
Actual results:
resolution of the guest doesn't change according to window size

Additional info:
There doesn't seem to be anything of much use in logs 

Nov  2 11:41:22.372098 spice-vdagentd: info: opening vdagent virtio channel
Nov  2 11:41:43.995096 spice-vdagentd: info: closed vdagent virtio channel
Nov  2 11:41:44.605959 spice-vdagentd: info: opening vdagent virtio channel
Nov  2 11:42:07.633969 spice-vdagentd: info: closed vdagent virtio channel

Comment 2 Tomas Jamrisko 2012-11-06 15:43:03 UTC
Well, tried getting a stack trace and it's not crashing. It exits with 1.

Comment 3 Marc-Andre Lureau 2012-11-21 16:11:28 UTC
I got it with current RHEL.

It is easy to reproduce, just remove /etc/xdg/autostart/spice-vdagent.desktop and start spice-vdagent -dddx manually

spice-vdagent[2985]: 0x1ba3010 received monitors config, arg1: 0, arg2: 0, size 28
spice-vdagent[2985]: from guest: 1, 1
spice-vdagent[2985]: received monitor 0 config 1440x823+0+0
spice-vdagent[2985]: after zeroing: 1, 1
spice-vdagent[2985]: received monitor 0 config 1440x823+0+0
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  16 (RRCreateMode)
  Serial number of failed request:  52
  Current serial number in output stream:  52

Comment 4 Marc-Andre Lureau 2012-11-21 16:28:27 UTC
(gdb) bt
#0  0x0000003ab3a45e70 in _XDefaultError () from /usr/lib64/libX11.so.6
#1  0x0000003ab3a45fbe in _XError () from /usr/lib64/libX11.so.6
#2  0x0000003ab3a42b27 in ?? () from /usr/lib64/libX11.so.6
#3  0x0000003ab3a43232 in _XReply () from /usr/lib64/libX11.so.6
#4  0x0000003ab6604cb5 in XRRCreateMode () from /usr/lib64/libXrandr.so.2
#5  0x00000000004064a5 in create_new_mode (x11=0x7ffff7f1e010, output_index=0, 
    width=1440, height=823) at src/vdagent-x11-randr.c:310
#6  0x00000000004065a0 in xrandr_add_and_set (x11=0x7ffff7f1e010, output=0, 
    x=0, y=0, width=1440, height=823) at src/vdagent-x11-randr.c:336
#7  0x000000000040742a in vdagent_x11_set_monitor_config (x11=0x7ffff7f1e010, 
    mon_config=0x61a020) at src/vdagent-x11-randr.c:662
#8  0x000000000040203a in daemon_read_complete (connp=0x60bc38, 
    header=0x60c044, data=0x61a020 "\001") at src/vdagent.c:55
#9  0x00000000004087b3 in udscs_read_complete (connp=0x60bc38)
    at src/udscs.c:460
#10 0x00000000004089e0 in udscs_do_read (connp=0x60bc38) at src/udscs.c:515
#11 0x0000000000408367 in udscs_client_handle_fds (connp=0x60bc38, 
    readfds=0x7fffffffdfd0, writefds=0x7fffffffdf50) at src/udscs.c:349
#12 0x0000000000402762 in main (argc=2, argv=0x7fffffffe178)
    at src/vdagent.c:239

Comment 5 Marc-Andre Lureau 2012-11-21 18:40:47 UTC
I think I found the reason.. It seems that both vdagent (gdm & user) compete in creating the mode, and most probably, the session one exit with an XError (could be gdm, but it is 100% session here, probably because spice-vdagentd deliver message first to it?).

The second RRModeCreateUser:

Breakpoint 1, RRModeCreateUser (pScreen=0xb36700, modeInfo=0xbfd7d8, name=0xbfd7f8 "vdagent-0", error=0x7ffff4dcb794) at rrmode.c:146
146	    mode = RRModeFindByName(name, modeInfo->nameLength);
(gdb) n
147	    if (mode) {
(gdb) 
148	        *error = BadName;
(gdb) 
149	        return NULL;

Comment 6 Alon Levy 2012-11-21 18:55:11 UTC
I don't understand how this is happening: the mode doesn't actually exist before vdagent adds it - how can it be competing with gdm, where does gdm know the mode to add, and why is it adding it? And what two RRModeCreateUser - I only see one callchain, the one the stack trace is showing in comment 4.

Comment 7 Marc-Andre Lureau 2012-11-21 23:31:32 UTC
Patch on the ML:

http://lists.freedesktop.org/archives/spice-devel/2012-November/011535.html

Comment 8 Marc-Andre Lureau 2012-11-26 11:50:16 UTC
please give acks!

Comment 10 Marian Krcmarik 2012-11-29 16:16:58 UTC
(In reply to comment #7)
> Patch on the ML:
> 
> http://lists.freedesktop.org/archives/spice-devel/2012-November/011535.html

Seems to be working fine now, go ahead with the build.

Comment 11 Marc-Andre Lureau 2012-11-29 16:26:53 UTC
in spice-vdagent-0.12.0-3.el6

Comment 16 errata-xmlrpc 2013-02-21 08:23:32 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.

http://rhn.redhat.com/errata/RHEA-2013-0311.html


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