Bug 1017250

Summary:	avoid some allocation failure on c&p
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	David Jaša <djasa>
Component:	mingw-virt-viewer	Assignee:	Marc-Andre Lureau <marcandre.lureau>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	acathrow, cfergeau, dblechte, mkrcmari, sherold, tpoitras, uril, yeylon
Target Milestone:	---
Target Release:	3.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	mingw-virt-viewer-0.5.6-21.el6_5 mingw-spice-gtk-0.20-6.el6_5 mingw-glib2-2.32.4-1.1.el6_5 mingw-gtk2-2.24.13-7.el6_5	Doc Type:	Bug Fix
Doc Text:	Previously, virt-viewer was unable to handle large copy and paste operations. If a very large amount of text was copied, then mingw-virt-viewer displayed a failure to allocate memory error. After fixing this bug, up to 100 MB of data can be copied and pasted.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-09 12:51:18 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:	1017790
Bug Blocks:	1019797, 1029162

Description David Jaša 2013-10-09 13:45:35 UTC

Description of problem:
When copying large amount of text (175 MB plaintext in my case), mingw-virt-viewer spawns a pop up about failure to allocate memory:
> (remote-viewer.exe:2964): GLib-ERROR **:../../glib/gmem.c:230: failed to allocate 536870912 bytes
followed by MSVC++ Runtime Library pop up:
> This application has requested the Runtime to terminate in an unusual way.
> Please contact the application's support team for more information.

IMO virt-viewer should handle such event gracefully, just refusing to do the c/p operation that triggered the allocation failure and continue to run as before.

I tried to reproduce with large image data (the largest image is about 80 MP) but then I hit other limits first (ability of target system app to receive such data etc.)

I'm setting severity to low because the use case shouldn't be frequent out in the wild but it would be nice to have this handled.

Version-Release number of selected component (if applicable):
mingw-virt-viewer-0.5.6-6.el6_4 32b

How reproducible:
frequent

Steps to Reproduce:
1. copy large text (175 MB in my case) from memory-limited client machine (<= 2GB in my case) to some guest
2.
3.

Actual results:
client exits with above error

Expected results:
client handles allocation failure

Additional info:

Comment 1 Marc-Andre Lureau 2013-10-09 13:56:17 UTC

Sorry, but I don't think we should handle such big clipboard. And a crash for OOM is the way gtk+ application are written.

However, we should try to handle cases where the clipboard size is ridiculously big (say over 100mb) and just discard copy operation, imho.

Comment 2 Marc-Andre Lureau 2013-10-09 14:20:04 UTC

The first offender, gtk+, does copy or some transformation of clipboard without size limits (utf16 to utf8 or dib/bmp). We would need to convince gtk+ maintainer to have clipboard memory limit or to handle OOM condition for more cases (they do for dib for instance).

Spice-gtk itself also does copy and transformation (crlf conversion), we would need to handle OOM condition for this case too or just drop big clipboard data by default (which is imho, a better alternative).

This shouldn't be too hard to improve to avoid the crash, but I'd consider this quite low priority.

Comment 3 Marc-Andre Lureau 2013-11-06 13:17:42 UTC

glib patch:
https://bugzilla.gnome.org/show_bug.cgi?id=711546

Comment 4 Marc-Andre Lureau 2013-11-06 15:20:09 UTC

gtk patch:
https://bugzilla.gnome.org/show_bug.cgi?id=711553

Comment 5 Marc-Andre Lureau 2013-11-06 21:34:56 UTC

sent patches for spice-gtk:
http://lists.freedesktop.org/archives/spice-devel/2013-November/015256.html

Comment 6 Marc-Andre Lureau 2013-11-07 14:19:54 UTC

devel ack, those patch already help for some case, but we don't have full solution yet. I would move to 3.4

Comment 8 David Blechter 2013-11-08 20:22:18 UTC

there are number of bugs related to copy/paste across supported platforms. 
We should creat the tracker bug and link all copy/paste bugs to it.

the 3.4 target sounds reasonable to address these issues.

Comment 11 Marc-Andre Lureau 2014-04-01 10:19:33 UTC

changing bug title to a realistic one. (there is *no* way we are going to handle oom conditions in spice-gtk)

Comment 15 errata-xmlrpc 2014-06-09 12:51:18 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/RHBA-2014-0644.html