Bug 857471

Hi,

(In reply to comment #0)
> 3. Use a clipboard script to put an image into the clipboard ~ to
> highlighting and copying an image from a guest

1) Can you please try reproducing the bug using the script on the client machine directly, ie tryong to copy paste from the client to the client using the script. Often people blame spice's cut and paste for bugs in other code... (ie xsel is notoriously buggy when dealing with large copy-pastes)

2) Can you please provide this script, so that we can try to reproduce this bug.

Thanks,

Hans

Hi Hans, 

I wrote the script using pygtk, it does have some bugs with large textual data on 6.3 I can't copy and paste 10mb of data like I want to.

But for the bug in question, it is part of an automated test, and I make sure the copy and paste is successfully locall prior to going to the other side (guest or client).  And it works from client to guest with a 3.5MB png image, it only fails guest to client, where it shows nothing is in the paste buffer.

I will attach the script, usage for copying and pasting images:

To copy:
python ./cb.py -i <Your_Image_toCopy>.png

To paste:
python ./cb.py -m <Name_for_Your_PastedImg>.png

Thanks,
Vimal

Created attachment 612927 [details]
Clipboard Script Using pygtk

(In reply to comment #3)
> Hi Hans, 
> 
> I wrote the script using pygtk, it does have some bugs with large textual
> data on 6.3 I can't copy and paste 10mb of data like I want to.

As I already told Marian, you should not be using pygtk if it turns out to not be reliable.
For the way data is moved between source and dest when doing copy and paste the
contents (text versus img) does not matter at all, there is 1 magic int giving the type
of the data, other then that the paths are identical, so if your test is unreliable with
text it will be unreliable with images too,

> But for the bug in question, it is part of an automated test, and I make
> sure the copy and paste is successfully locall prior to going to the other
> side (guest or client)

Doing a local test first is a decent sanity check, but in no way rules out bugs
in either sender or receiver when doing copy paste, local it goes like this:
src -> dst

With spice involved it goes:
src -> vdagent -> spice-client ->dst

So rather then talking directly to each other, from the X11 selections mechanism pov the src only sees the agent, and the dest only the client.

> And it works from client to guest with a 3.5MB png
> image, it only fails guest to client, where it shows nothing is in the paste
> buffer.

The source of the data is the one who decides in which size chunks the data gets chopped before
sending, so there can be a huge difference between the 2 directions.

I'm sorry but I really don't have the time to debug this right now, and I cannot help but feel that your test-method is causing the issues not the actual code.

Can you try creating a vm with a high resolution, then put lots of different stuff on the screen (to acoid it compressing well, a nice "busy" photo as background should work well) and hit printscreen inside the vm, then select copy to clipboard for the screenshot, then on the client open gimp and do a paste there, that is how I usually test, and those screenshots easily go over the mentioned 216Kb, also people have tested sending megabytes over using xsel and that works too, so I really think the testing method is flawed here.

As I already told Marian, it would probably be best to use xsel for clipboard tests, yes I just said it was buggy, and it is, but its bugs are known and have been fixed. If you do use xsel, please rebuild the latest Fedora package, as the epel on is missing an important bugfix (and while at it feel free to file a bug against xsel in epel for this).

Also not unimportant is the versions of the software on the host you are using. Are you perhaps doing this on a host which has the new seamless migration packages? Those are known to cause some problems with the agent channel, which are still being debugged ...

Hi Hans,

I tried it manually on a different setup with virtmanager still (RHEL 63 client and guest) with around a 500KB image from the guest, which is unable to be pasted on the client.  I tried a much smaller image and it worked.  

I tried a screenshot from the client to guest and it worked fine around 1MB

Pygtk seemed pretty stable to me when automating the tests I looked into xsel, xclip, and pygtk and found pygtk to be the best.  taking screenshots manually and using the script on the other end.  And all my tests use an md5sum to make sure the images are copied exactly as expected.

Thanks,
Vimal

(In reply to comment #6)
> Hi Hans,
> 
> I tried it manually on a different setup with virtmanager still (RHEL 63
> client and guest) with around a 500KB image from the guest, which is unable
> to be pasted on the client.  I tried a much smaller image and it worked.  

With manually you mean you tried the screenshot copy to clipboard from guest to client,
iow the same way you tested the 1MB image in the other direction:

> I tried a screenshot from the client to guest and it worked fine around 1MB

?

Also I still need to know the exact versions of qemu and spice-server on the host where you're seeing this ...

Hi Hans,

Here is the information of the packages which is the host & client:
spice-gtk-python-0.11-11.el6.x86_64
spice-usb-share-4.9-9.el6.x86_64
spice-server-0.10.1-10.el6.x86_64
spice-gtk-0.11-11.el6.x86_64
spice-client-0.8.2-15.el6.x86_64
spice-vdagent-0.8.1-3.el6.x86_64
kmod-kspiceusb-rhel60-4.9-14.el6.x86_64
spice-glib-0.11-11.el6.x86_64
spice-xpi-2.7-20.el6.x86_64
usbredir-0.4.3-1.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.295.el6.x86_64
qemu-kvm-0.12.1.2-2.295.el6.x86_64
xorg-x11-drv-qxl-0.0.14-13.el6_2.x86_64
virt-viewer-0.5.2-9.el6.x86_64
libvirt-client-0.9.10-21.el6_3.1.x86_64
libvirt-python-0.9.10-21.el6_3.1.x86_64
libvirt-0.9.10-21.el6_3.1.x86_64

I tried what you suggested taking screenshots and using gimp.  Gimp seemed to have a problem locally pasting a screenshot, so trying to use it for testing between the client and guest was not possible.  But if I did a printscreen and used the cb.py script, I was able to paste the data locally.  So I was unable to test this way.

So I tried printscreen on the client -> python cb.py -m image on guest - Works (a little less than 1MB)
&  I tried printscreen on the guest -> python cb.py -m image on the client - Fails, but doing it locally on the guest it works. (around 750kb)

To reiterate, I was only able to test this using the script.  There seems to be an issue because I am able to copy and paste locally with the script, I am able to copy from the client to guest using the script, and I am able to copy small images from guest to client, but I can't copy medium to large size pics from guest to client, that's where I believe there is an issue.

Is there something else that you would like me to try to test?

Hans,

I tested doing a screenshot, using the gnome-panel-screenshot, copying and pasting the screenshot from guest to client works as long as gnome-panel-screenshot is left open, after it is closed it no longer works, but using the cb.py script it can still be seen locally.  I think there is some kind of issue here, but I can't pinpoint it, but you are correct that the data can be sent over from guest to client.

Vimal

I tried the same test using F17 with an updated pygtk package and the test works.  Closing this bug as NOTABUG, need to get updated packages for RHEL 6.3 testing.

Andrei, why did you clone that bug?

Guest:
spice-vdagent-0.14.0-5.el6.i686

Client:
spice-vdagent-0.14.0-4.el6.x86_64
spice-gtk-0.22-7.el6.x86_64
spice-xpi-2.7-25.el6.x86_64
spice-glib-0.22-7.el6.x86_64

Is this again a i686 guest bug only?
Can you check /var/log/messages for vdagent error and check if it's still running?

x86_64 guest also has this bug.
After Copy/Paste spice-vdagent keeps running.

I found new strange thing after unsuccessful Copy/Paste action:
context menu disappears for right mouse click in gedit and gnome-terminal.

Direction: copy in guest and paste in client also has this bug.

Using rhel6 client & f21 guest on f21 host, I can't reproduce. What's the host?

Could you check the spice-vdagent log too?

RHEVM: 3.5.1-0.1.el6ev
Hosts are: Rhel7 for one cluster, Rhel6 for the another cluster.

/var/log/spice-vdagent.log prints:

Mar 30 14:52:59.375177 spice-vdagent[2650]: err: clipboard: selection requests pending on clipboard ownership change, clearing

But, I have received this kind of messages frequently before.

Have you used the attached PNG file for tests ?

(In reply to Andrei Stepanov from comment #20)
> Have you used the attached PNG file for tests ?

yes

hi, is it only LibreOficeDraw specific? can you try copying it using gimp ?

Copy/paste fails for: Client LibreOficeDraw -> Guest LibreOficeDraw

Copy/paste works fine for:
Client LibreOficeDraw -> Guest Gimp
Client Gimp -> Guest LibreOficeDraw

All tests use same PNG-file.

(In reply to Andrei Stepanov from comment #23)
> Copy/paste fails for: Client LibreOficeDraw -> Guest LibreOficeDraw
> 
> Copy/paste works fine for:
> Client LibreOficeDraw -> Guest Gimp
> Client Gimp -> Guest LibreOficeDraw
> 
> All tests use same PNG-file.

What version of LibreOffice have you used in the Guest and Client?

Considering they are the same version, can you reproduce the copy and paste problem in a physical machine?

I cannot reproduce it:

With client:
libreoffice-draw-4.2.8.2-11.el6.x86_64

Guests:
libreoffice-draw-4.2.8.2-11.el6.x86_64
libreoffice-draw-4.2.8.2-11.el6.i686