Bug 872633 - Vdagent stops when first resizing a window
Vdagent stops when first resizing a window
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-vdagent (Show other bugs)
6.4
Unspecified Unspecified
high Severity unspecified
: rc
: ---
Assigned To: Alon Levy
Desktop QE
:
Depends On:
Blocks: 842355 881827
  Show dependency treegraph
 
Reported: 2012-11-02 12:00 EDT by Tomas Jamrisko
Modified: 2013-07-03 08:12 EDT (History)
9 users (show)

See Also:
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 03:23:32 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)

  None (edit)
Description Tomas Jamrisko 2012-11-02 12:00:35 EDT
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 10:43:03 EST
Well, tried getting a stack trace and it's not crashing. It exits with 1.
Comment 3 Marc-Andre Lureau 2012-11-21 11:11:28 EST
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 11:28:27 EST
(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 13:40:47 EST
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 13:55:11 EST
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 18:31:32 EST
Patch on the ML:

http://lists.freedesktop.org/archives/spice-devel/2012-November/011535.html
Comment 8 Marc-Andre Lureau 2012-11-26 06:50:16 EST
please give acks!
Comment 10 Marian Krcmarik 2012-11-29 11:16:58 EST
(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 11:26:53 EST
in spice-vdagent-0.12.0-3.el6
Comment 16 errata-xmlrpc 2013-02-21 03:23:32 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.

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.