Bug 872633

Summary: Vdagent stops when first resizing a window
Product: Red Hat Enterprise Linux 6 Reporter: Tomas Jamrisko <tjamrisk>
Component: spice-vdagentAssignee: Alon Levy <alevy>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: high    
Version: 6.4CC: acathrow, alevy, cfergeau, dblechte, dyasny, hdegoede, marcandre.lureau, mbarta, mkrcmari
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spice-vdagent-0.12.0-3.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 08:23:32 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:
Bug Depends On:    
Bug Blocks: 842355, 881827    

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