[Spice-devel] Fedora 19 and 20 spice guest Xorg crashes

[Nahum Shalman]

Context:
Host is running qemu-kvm 1.1.2 and spice 0.12.2.
Fedora 16 VMs ran rock solid on these same virtualization hosts.
The Fedora 19 and 20(testing) VMs are running xf86-video-qxl compiled 
from the master branch of the git repo.

We've been seeing a lot of X server crashes in Fedora 19 and 20, 
generally after the VM has been running for at least 2-3 days.
The last gasp in the Xorg logs from these crashes generally look 
something like:

[1024592.839] Out of memory allocating 261140 bytes
[1024592.839] Out of mem - stats

[1024592.850] max system bytes =  243257344
[1024592.850] system bytes     =  243257344
[1024592.850] in use bytes     =  133245384

Someone here managed to get a stack trace out of one such crash:

(EE) [mi] EQ overflowing. Additional events will be discarded until 
existing events are processed.
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/X (mieqEnqueue+0x22b) [0x57691b]
(EE) 1: /usr/bin/X (QueuePointerEvents+0x52) [0x44d862]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (_init+0x2913) 
[0x7ff0faeb17e3]
(EE) 3: /usr/bin/X (DPMSSupported+0xe8) [0x4861f8]
(EE) 4: /usr/bin/X (xf86SerialModemClearBits+0x230) [0x4ae7b0]
(EE) 5: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x3b7de0ef9f]
(EE) 6: /lib64/libpthread.so.0 (__nanosleep_nocancel+0x24) [0x3b7de0e804]
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (qxl_handle_oom+0x69) 
[0x7ff10fceccb9]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (qxl_allocnf+0x48) 
[0x7ff10fcecd08]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(qxl_bo_alloc_internal+0x76) [0x7ff10fcece06]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(qxl_image_create+0xf2) [0x7ff10fce9782]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(qxl_surface_put_image+0xf5) [0x7ff10fceb045]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so 
(uxa_copy_n_to_n+0x5e7) [0x7ff10fcf7127]
(EE) 13: /usr/bin/X (miCopyRegion+0x1ad) [0x574d2d]
(EE) 14: /usr/bin/X (miDoCopy+0x456) [0x5752b6]
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (uxa_copy_area+0xae) 
[0x7ff10fcf5efe]
(EE) 16: /usr/bin/X (dixDestroyPixmap+0x711) [0x433a31]
(EE) 17: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fa7]
(EE) 18: /usr/bin/X (_init+0x3aaa) [0x429b4a]
(EE) 19: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3b7d221b75]
(EE) 20: /usr/bin/X (_start+0x29) [0x4267b1]
(EE) 21: ? (?+0x29) [0x29]
(EE)
(EE) [mi] These backtraces from mieqEnqueue may point to a culprit 
higher up the stack.
(EE) [mi] mieq is *NOT* the cause. It is a victim.
(EE) [mi] EQ overflow continuing. 100 events have been dropped.

His comment was:

Examining the stack trace more closely, the functions identified are 
misleading. The offsets are sometimes larger than the named functions, 
and point to different functions not listed in the stripped symbol 
table. Looking at the source, it seems that:

(EE) 16: /usr/bin/X (dixDestroyPixmap+0x711) [0x433a31]

  * This is probably ProcCreatePixmap()

(EE) 17: /usr/bin/X (SendErrorToClient+0x3f7) [0x436fa7]

  * This is possibly init_screen() or AddScreen()

So, it appears the memory allocation fails while setting up a new screen 
structure. This makes more sense, but still leaves open the question why 
it's trying to create new screens long after startup.

It's hard to recreate the crashes other than by simply booting and using 
a VM for a few days. One theory we're tossing around is that the memory 
buffer xf86-video-qxl has to work with is getting fragmented and when 
the fragmentation gets bad enough an allocation can fail.
Our best guess is that this is a bug in the xf86-video-qxl driver. Has 
anyone else seen similar Xorg crashes?

Guidance on how to fix or at least troubleshoot this further would be 
greatly appreciated.

Thanks!
-Nahum

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20131118/76e529fe/attachment.html>