Bug 1017250 - avoid some allocation failure on c&p
avoid some allocation failure on c&p
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity low
: ---
: 3.4.0
Assigned To: Marc-Andre Lureau
Desktop QE
:
Depends On: 1017790
Blocks: 1019797 1029162
  Show dependency treegraph
 
Reported: 2013-10-09 09:45 EDT by David Jaša
Modified: 2014-06-09 08:51 EDT (History)
8 users (show)

See Also:
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 08:51:18 EDT
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 David Jaša 2013-10-09 09:45:35 EDT
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 09:56:17 EDT
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 10:20:04 EDT
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 08:17:42 EST
glib patch:
https://bugzilla.gnome.org/show_bug.cgi?id=711546
Comment 4 Marc-Andre Lureau 2013-11-06 10:20:09 EST
gtk patch:
https://bugzilla.gnome.org/show_bug.cgi?id=711553
Comment 5 Marc-Andre Lureau 2013-11-06 16:34:56 EST
sent patches for spice-gtk:
http://lists.freedesktop.org/archives/spice-devel/2013-November/015256.html
Comment 6 Marc-Andre Lureau 2013-11-07 09:19:54 EST
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 15:22:18 EST
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 06:19:33 EDT
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 08:51:18 EDT
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

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