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:
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.
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.
glib patch: https://bugzilla.gnome.org/show_bug.cgi?id=711546
gtk patch: https://bugzilla.gnome.org/show_bug.cgi?id=711553
sent patches for spice-gtk: http://lists.freedesktop.org/archives/spice-devel/2013-November/015256.html
devel ack, those patch already help for some case, but we don't have full solution yet. I would move to 3.4
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.
changing bug title to a realistic one. (there is *no* way we are going to handle oom conditions in spice-gtk)
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