1158879 – Xorg crashes randomly after updating to Red Hat Enterprise Linux 6.6.0

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1158879 - Xorg crashes randomly after updating to Red Hat Enterprise Linux 6.6.0

Summary: Xorg crashes randomly after updating to Red Hat Enterprise Linux 6.6.0

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	xorg-x11-drv-qxl
Sub Component:
Version:	6.6
Hardware:	x86_64
OS:	Linux
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Default Assignee for SPICE Bugs
QA Contact:	SPICE QE bug list
Docs Contact:
URL:
Whiteboard:
Duplicates (1):	1170234 (view as bug list)
Depends On:
Blocks:	1075802
TreeView+	depends on / blocked

Reported:	2014-10-30 12:37 UTC by Siteshwar Vashisht
Modified:	2020-03-11 14:52 UTC (History)
CC List:	18 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2015-04-02 11:25:43 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
RPM which was attached to bug #1192154 (91.61 KB, application/x-rpm) 2015-02-17 13:04 UTC, Christophe Fergeau	no flags	Details
Test RPM (91.86 KB, application/x-rpm) 2015-03-24 13:31 UTC, Christophe Fergeau	no flags	Details
View All

Description Siteshwar Vashisht 2014-10-30 12:37:41 UTC

Description of problem:
Xorg crashes randomly after updating to Red Hat Enterprise Linux 6.6.0

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.15.0-22.el6.x86_64

How reproducible:
Sometimes

Additional info:

Backtrace of the crash :

Thread 1 (Thread 0x7fa779f0d920 (LWP 17809)):
#0  0x000000385be32625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x000000385be33e05 in abort () at abort.c:92
#2  0x00000000005af82e in OsAbort () at utils.c:1330
#3  0x00000000005b74b1 in FatalError (f=0x5e0640 "Caught signal %d (%s). Server aborting\n") at log.c:914
#4  0x00000000005ae9ee in OsSigHandler (signo=11, sip=<value optimized out>, unused=<value optimized out>) at osinit.c:147
#5  <signal handler called>
#6  0x00000000005b29dd in _XSERVTransClose (ciptr=0x1487b90) at /usr/include/X11/Xtrans/Xtrans.c:960
#7  0x00000000005ab6ef in CloseWellKnownConnections () at connection.c:520
#8  0x00000000005b6829 in AbortServer () at log.c:767
#9  0x00000000005b74f4 in FatalError (f=0x5c9cc5 "%s: VT_ACTIVATE failed: %s\n") at log.c:911
#10 0x00000000004a47cb in switch_to (vt=1, from=0x5c9cff "xf86CloseConsole") at lnx_init.c:72
#11 0x00000000004a4962 in xf86CloseConsole () at lnx_init.c:308
#12 0x000000000047c32d in ddxGiveUp (error=EXIT_NO_ERROR) at xf86Init.c:1092
#13 0x000000000043cae0 in dix_main (argc=11, argv=<value optimized out>, envp=<value optimized out>) at main.c:374
#14 0x000000385be1ed5d in __libc_start_main (main=0x426a90 <main>, argc=11, ubp_av=0x7fff233f7de8, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fff233f7dd8) at libc-start.c:226
#15 0x00000000004269c9 in _start ()

Comment 1 Siteshwar Vashisht 2014-10-31 09:26:12 UTC

Another crash was observed on the same system but it has different stacktrace :

Thread 1 (Thread 0x7fee09cbe920 (LWP 8056)):
#0  mspace_malloc (msp=0x7fee05f4c010, bytes=<value optimized out>) at mspace.c:2253
#1  0x00007fee091652aa in qxl_alloc (qxl=0x225ad10, size=150, name=<value optimized out>) at qxl_mem.c:141
#2  qxl_allocnf (qxl=0x225ad10, size=150, name=<value optimized out>) at qxl_mem.c:419
#3  0x00007fee091653b5 in qxl_bo_alloc_internal (qxl=0x225ad10, type=4, flags=<value optimized out>, size=150, name=0x7fee09180e1c "cursor command") at qxl_mem.c:480
#4  0x00007fee09167dc7 in qxl_alloc_cursor_cmd (qxl=0x225ad10) at qxl_cursor.c:43
#5  0x00007fee09167f0d in qxl_hide_cursor (pScrn=<value optimized out>) at qxl_cursor.c:162
#6  0x00000000004c152b in xf86CursorSetCursor (pDev=0x2c988e0, pScreen=0x229c9d0, pCurs=0x0, x=100, y=75) at xf86Cursor.c:313
#7  0x00000000004c17d7 in xf86CursorEnableDisableFBAccess (pScrn=0x225a6d0, enable=0) at xf86Cursor.c:217
#8  0x00007fee0915ffb8 in qxl_leave_vt (arg=<value optimized out>) at qxl_driver.c:878
#9  0x000000000047c3cb in AbortDDX (error=EXIT_ERR_ABORT) at xf86Init.c:1131
#10 0x00000000005b6842 in AbortServer () at log.c:770
#11 0x00000000005b74f4 in FatalError (f=0x5e0640 "Caught signal %d (%s). Server aborting\n") at log.c:911
#12 0x00000000005ae9ee in OsSigHandler (signo=11, sip=<value optimized out>, unused=<value optimized out>) at osinit.c:147
#13 <signal handler called>
#14 mspace_malloc (msp=0x7fee05f4c010, bytes=<value optimized out>) at mspace.c:2253
#15 0x00007fee091652aa in qxl_alloc (qxl=0x225ad10, size=150, name=<value optimized out>) at qxl_mem.c:141
#16 qxl_allocnf (qxl=0x225ad10, size=150, name=<value optimized out>) at qxl_mem.c:419
#17 0x00007fee091653b5 in qxl_bo_alloc_internal (qxl=0x225ad10, type=4, flags=<value optimized out>, size=150, name=0x7fee09180e1c "cursor command") at qxl_mem.c:480
#18 0x00007fee09167dc7 in qxl_alloc_cursor_cmd (qxl=0x225ad10) at qxl_cursor.c:43
#19 0x00007fee09167f0d in qxl_hide_cursor (pScrn=<value optimized out>) at qxl_cursor.c:162
#20 0x00000000004c2a7e in xf86SetCursor (pScreen=0x229c9d0, pCurs=0x31e6ae0, x=88, y=63) at xf86HWCurs.c:152
#21 0x00000000004c16da in xf86CursorSetCursor (pDev=0x2c988e0, pScreen=0x229c9d0, pCurs=0x31e6ae0, x=100, y=75) at xf86Cursor.c:355
#22 0x00000000005957a2 in miPointerUpdateSprite (pDev=0x2c988e0) at mipointer.c:443
#23 0x0000000000595aa0 in miPointerDisplayCursor (pDev=0x2c988e0, pScreen=0x229c9d0, pCursor=0x31e6ae0) at mipointer.c:194
#24 0x00000000004d120f in CursorDisplayCursor (pDev=0x2c988e0, pScreen=0x229c9d0, pCursor=0x31e6ae0) at cursor.c:150
#25 0x000000000052247a in AnimCurScreenBlockHandler (pScreen=0x229c9d0, pTimeout=0x7fff49f8df68, pReadmask=0x83dac0) at animcur.c:167
#26 0x000000000043cd3a in BlockHandler (pTimeout=0x7fff49f8df68, pReadmask=0x83dac0) at dixutils.c:387
#27 0x00000000005a7b7c in WaitForSomething (pClientsReady=0x2e5b120) at WaitFor.c:215
#28 0x00000000004389f2 in Dispatch () at dispatch.c:362
#29 0x000000000043c83a in dix_main (argc=11, argv=<value optimized out>, envp=<value optimized out>) at main.c:294
#30 0x000000385be1ed5d in __libc_start_main (main=0x426a90 <main>, argc=11, ubp_av=0x7fff49f8e188, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fff49f8e178) at libc-start.c:226
#31 0x00000000004269c9 in _start ()

Comment 3 Marc-Andre Lureau 2014-12-12 15:10:54 UTC

No reproducer?

Comment 4 Siteshwar Vashisht 2014-12-22 12:47:33 UTC

We have not been able to reproduce this issue on our test systems.

Comment 5 Marc-Andre Lureau 2014-12-22 12:49:47 UTC

(In reply to Siteshwar Vashisht from comment #4)
> We have not been able to reproduce this issue on our test systems.

keeping needinfo, eventually close as insufficient data if no duplicates or reproducer

Comment 7 Siteshwar Vashisht 2015-01-07 11:35:12 UTC

No reproducer yet but I noticed below messages in /var/log/Xorg.0.log.old after crash :

(EE) [mi] EQ overflowing.  Additional events will be discarded until existing events are processed.
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aa5a1]
(EE) 1: /usr/bin/Xorg (mieqEnqueue+0x273) [0x58ab13]
(EE) 2: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45147e]
(EE) 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7faac67ac000+0x46f2) [0x7faac67b06f2]
(EE) 4: /usr/bin/Xorg (0x400000+0x7a267) [0x47a267]
(EE) 5: /usr/bin/Xorg (0x400000+0xa3dcb) [0x4a3dcb]
(EE) 6: /lib64/libpthread.so.0 (0x3db7a00000+0xf710) [0x3db7a0f710]
(EE) 7: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x3db7a0ef20]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7faad0a4b000+0xafab) [0x7faad0a55fab]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7faad0a4b000+0xb2c3) [0x7faad0a562c3]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7faad0a4b000+0xb3b5) [0x7faad0a563b5]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7faad0a4b000+0x7abb) [0x7faad0a52abb]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7faad0a4b000+0x82c8) [0x7faad0a532c8]
(EE) 13: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7faad0a4b000+0x1a5d0) [0x7faad0a655d0]
(EE) 14: /usr/bin/Xorg (miCopyRegion+0xa5) [0x588a35]
(EE) 15: /usr/bin/Xorg (miDoCopy+0x44a) [0x5890da]
(EE) 16: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7faad0a4b000+0x19b1e) [0x7faad0a64b1e]
(EE) 17: /usr/bin/Xorg (0x400000+0x12a468) [0x52a468]
(EE) 18: /usr/bin/Xorg (0x400000+0x35f19) [0x435f19]
(EE) 19: /usr/bin/Xorg (0x400000+0x38dd6) [0x438dd6]
(EE) 20: /usr/bin/Xorg (0x400000+0x3c83a) [0x43c83a]
(EE) 21: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3db761ed5d]
(EE) 22: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(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.

Comment 8 Marc-Andre Lureau 2015-01-21 13:05:54 UTC

well, we have 3 different backtraces here, and no reproducer. It may be that the cause it the same, but it's hard to do anything about it at this point.

Please make sure you have all debug symbols installed, qxl_drv.so is missing symbols in last stack trace. In last cases, it looks like qxl driver is stuck calling nanosleep, and this usually happen in OOM cases. Can you provide some hint on what you did, the version of xf86 qxl & qemu, the qemu arguments..

thanks

Comment 13 bugzilla 2015-01-26 08:56:48 UTC

I have the same problem, with the same output in my Xorg log file.

Description of problem:
Xorg crashes randomly after updating to Red Hat Enterprise Linux 6.6.0.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Workstation release 6.6 (Santiago)
xorg-x11-server-Xorg-1.15.0-25.el6_6.x86_64
xorg-x11-drv-qxl-0.1.1-15.el6.x86_64
gpxe-roms-qemu-0.9.7-6.12.el6.noarch
qemu-img-0.12.1.2-2.448.el6_6.x86_64
qemu-kvm-0.12.1.2-2.448.el6_6.x86_64

How reproducible:
Always.  Ever since upgrading to RHEL 6.6 last year, X freezes/crashes and restarts every weekend when I use firefox (in a known good fully patched clean snapshot RHEL 6.6 guest VM, running on a fully patched RHEL 6.6 host) to read approximately 150 news articles from the web sites www.zdnet.com and www.theregister.co.uk.

Steps to Reproduce:
1. Run firefox.
2. Use firefox to view at least 150 news articles from the web sites www.zdnet.com and www.theregister.co.uk.  Note: I'm not stating that all of these news articles have to be open at the same time in hundreds of web browser tabs, I usually have a maximum of 20 web browser tabs open at any time.

Actual results:
X freezes/crashes and restarts and I have to log back in again.

Expected results:
Web browsing uninterrupted by X freezing/crashing and restarting.

Additional info:

Here are two separate extracts from /var/log/Xorg.0.log.old after two occasions of X crashing.  Noting the above comment from Marc-Andre Lureau "it looks like qxl driver is stuck calling nanosleep, and this usually happen in OOM cases", note the "Out of memory" errors at the bottom of each log file, even though the log states that only half of the memory was in use at the time of the crash.  [Speculation:] I assume this means video memory since [fact:] there is plenty (GB) of unused operating system RAM available when X crashes.

Also, I have included software version information, as well as qemu command line parameters related to qxl.

Let me know what terminal commands you would like me to run in the guest VM or on the host operating system, to help further troubleshoot this bug.

======================================================
First example extract from /var/log/Xorg.0.log.old
======================================================

(EE) [mi] EQ overflowing.  Additional events will be discarded until existing events are processed.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (mieqEnqueue+0x273) [0x58b2f3]
(EE) 2: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f28ac114000+0x46f2) [0x7f28ac1186f2]
(EE) 4: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 5: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 6: /lib64/libpthread.so.0 (0x7f28bb2e4000+0xf710) [0x7f28bb2f3710]
(EE) 7: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x7f28bb2f2f20]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0xafab) [0x7f28b65e5fab]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0xb2c3) [0x7f28b65e62c3]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0xb3b5) [0x7f28b65e63b5]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x7abb) [0x7f28b65e2abb]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x82c8) [0x7f28b65e32c8]
(EE) 13: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x1a5d0) [0x7f28b65f55d0]
(EE) 14: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 15: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 16: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x19b1e) [0x7f28b65f4b1e]
(EE) 17: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 18: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 19: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 20: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 21: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f28b8fa6d5d]
(EE) 22: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(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.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f28ac114000+0x46f2) [0x7f28ac1186f2]
(EE) 3: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 4: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 5: /lib64/libpthread.so.0 (0x7f28bb2e4000+0xf710) [0x7f28bb2f3710]
(EE) 6: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x7f28bb2f2f20]
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0xafab) [0x7f28b65e5fab]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0xb2c3) [0x7f28b65e62c3]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0xb3b5) [0x7f28b65e63b5]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x7abb) [0x7f28b65e2abb]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x82c8) [0x7f28b65e32c8]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x1a5d0) [0x7f28b65f55d0]
(EE) 13: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 14: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f28b65db000+0x19b1e) [0x7f28b65f4b1e]
(EE) 16: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 17: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 18: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 19: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f28b8fa6d5d]
(EE) 21: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(EE) 
[ 15205.666] Out of memory allocating 259960 bytes
[ 15205.666] Out of mem - stats
[ 15205.670] max system bytes =   50319360
[ 15205.670] system bytes     =   50319360
[ 15205.670] in use bytes     =   33438760

======================================================
Second example extract from /var/log/Xorg.0.log.old
======================================================

(EE) [mi] EQ overflowing.  Additional events will be discarded until existing events are processed.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (mieqEnqueue+0x273) [0x58b2f3]
(EE) 2: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f2d85ee4000+0x46f2) [0x7f2d85ee86f2]
(EE) 4: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 5: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 6: /lib64/libpthread.so.0 (0x35f0400000+0xf710) [0x35f040f710]
(EE) 7: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x35f040ef20]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xafab) [0x7f2d9018dfab]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb2c3) [0x7f2d9018e2c3]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb3b5) [0x7f2d9018e3b5]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x7abb) [0x7f2d9018aabb]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x82c8) [0x7f2d9018b2c8]
(EE) 13: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x1a5d0) [0x7f2d9019d5d0]
(EE) 14: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 15: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 16: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x19b1e) [0x7f2d9019cb1e]
(EE) 17: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 18: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 19: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 20: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 21: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x35f001ed5d]
(EE) 22: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(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.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f2d85ee4000+0x46f2) [0x7f2d85ee86f2]
(EE) 3: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 4: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 5: /lib64/libpthread.so.0 (0x35f0400000+0xf710) [0x35f040f710]
(EE) 6: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x35f040ef20]
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xafab) [0x7f2d9018dfab]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb2c3) [0x7f2d9018e2c3]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb3b5) [0x7f2d9018e3b5]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x7abb) [0x7f2d9018aabb]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x82c8) [0x7f2d9018b2c8]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x1a5d0) [0x7f2d9019d5d0]
(EE) 13: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 14: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x19b1e) [0x7f2d9019cb1e]
(EE) 16: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 17: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 18: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 19: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x35f001ed5d]
(EE) 21: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(EE) 
(EE) [mi] EQ overflow continuing.  200 events have been dropped.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f2d85ee4000+0x46f2) [0x7f2d85ee86f2]
(EE) 3: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 4: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 5: /lib64/libpthread.so.0 (0x35f0400000+0xf710) [0x35f040f710]
(EE) 6: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x35f040ef20]
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xafab) [0x7f2d9018dfab]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb2c3) [0x7f2d9018e2c3]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb3b5) [0x7f2d9018e3b5]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x7abb) [0x7f2d9018aabb]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x82c8) [0x7f2d9018b2c8]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x1a5d0) [0x7f2d9019d5d0]
(EE) 13: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 14: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x19b1e) [0x7f2d9019cb1e]
(EE) 16: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 17: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 18: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 19: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x35f001ed5d]
(EE) 21: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(EE) 
(EE) [mi] EQ overflow continuing.  300 events have been dropped.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f2d85ee4000+0x46f2) [0x7f2d85ee86f2]
(EE) 3: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 4: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 5: /lib64/libpthread.so.0 (0x35f0400000+0xf710) [0x35f040f710]
(EE) 6: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x35f040ef20]
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xafab) [0x7f2d9018dfab]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb2c3) [0x7f2d9018e2c3]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb3b5) [0x7f2d9018e3b5]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x7abb) [0x7f2d9018aabb]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x82c8) [0x7f2d9018b2c8]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x1a5d0) [0x7f2d9019d5d0]
(EE) 13: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 14: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x19b1e) [0x7f2d9019cb1e]
(EE) 16: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 17: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 18: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 19: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x35f001ed5d]
(EE) 21: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(EE) 
(EE) [mi] EQ overflow continuing.  400 events have been dropped.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f2d85ee4000+0x46f2) [0x7f2d85ee86f2]
(EE) 3: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 4: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 5: /lib64/libpthread.so.0 (0x35f0400000+0xf710) [0x35f040f710]
(EE) 6: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x35f040ef20]
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xafab) [0x7f2d9018dfab]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb2c3) [0x7f2d9018e2c3]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb3b5) [0x7f2d9018e3b5]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x7abb) [0x7f2d9018aabb]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x82c8) [0x7f2d9018b2c8]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x1a5d0) [0x7f2d9019d5d0]
(EE) 13: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 14: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x19b1e) [0x7f2d9019cb1e]
(EE) 16: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 17: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 18: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 19: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x35f001ed5d]
(EE) 21: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(EE) 
(EE) [mi] EQ overflow continuing.  500 events have been dropped.
(EE) 
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aade1]
(EE) 1: /usr/bin/Xorg (QueuePointerEvents+0x4e) [0x45154e]
(EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f2d85ee4000+0x46f2) [0x7f2d85ee86f2]
(EE) 3: /usr/bin/Xorg (0x400000+0x7a3c7) [0x47a3c7]
(EE) 4: /usr/bin/Xorg (0x400000+0xa4c0b) [0x4a4c0b]
(EE) 5: /lib64/libpthread.so.0 (0x35f0400000+0xf710) [0x35f040f710]
(EE) 6: /lib64/libpthread.so.0 (__nanosleep+0x10) [0x35f040ef20]
(EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xafab) [0x7f2d9018dfab]
(EE) 8: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb2c3) [0x7f2d9018e2c3]
(EE) 9: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0xb3b5) [0x7f2d9018e3b5]
(EE) 10: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x7abb) [0x7f2d9018aabb]
(EE) 11: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x82c8) [0x7f2d9018b2c8]
(EE) 12: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x1a5d0) [0x7f2d9019d5d0]
(EE) 13: /usr/bin/Xorg (miCopyRegion+0xa5) [0x589215]
(EE) 14: /usr/bin/Xorg (miDoCopy+0x44a) [0x5898ba]
(EE) 15: /usr/lib64/xorg/modules/drivers/qxl_drv.so (0x7f2d90183000+0x19b1e) [0x7f2d9019cb1e]
(EE) 16: /usr/bin/Xorg (0x400000+0x12aa28) [0x52aa28]
(EE) 17: /usr/bin/Xorg (0x400000+0x35f99) [0x435f99]
(EE) 18: /usr/bin/Xorg (0x400000+0x38e86) [0x438e86]
(EE) 19: /usr/bin/Xorg (0x400000+0x3c8ea) [0x43c8ea]
(EE) 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x35f001ed5d]
(EE) 21: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
(EE) 
[ 38486.997] Out of memory allocating 260256 bytes
[ 38486.997] Out of mem - stats
[ 38487.000] max system bytes =   50319360
[ 38487.000] system bytes     =   50319360
[ 38487.000] in use bytes     =   22741728

======================================================

Command run on GUEST operating system:
# cat /etc/redhat-release 
Red Hat Enterprise Linux Workstation release 6.6 (Santiago)

Command run on HOST operating system:
# cat /etc/redhat-release 
Red Hat Enterprise Linux Workstation release 6.6 (Santiago)

Command run on GUEST operating system:
# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i server-Xorg
xorg-x11-server-Xorg-1.15.0-25.el6_6.x86_64

Command run on HOST operating system:
# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i server-Xorg
xorg-x11-server-Xorg-1.15.0-25.el6_6.x86_64

Command run on GUEST operating system:
# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i qxl
xorg-x11-drv-qxl-0.1.1-15.el6.x86_64

Command run on HOST operating system:
# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i qxl
xorg-x11-drv-qxl-0.1.1-15.el6.x86_64

Command run on HOST operating system:
# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i qemu
gpxe-roms-qemu-0.9.7-6.12.el6.noarch
qemu-img-0.12.1.2-2.448.el6_6.x86_64
qemu-kvm-0.12.1.2-2.448.el6_6.x86_64

The HOST operating system runs /usr/libexec/qemu-kvm with the following command line parameters related to qxl:
-chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864

The relevant xml file in /etc/libvirt/qemu contains the following extract:
    <video>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </memballoon>

[Speculation:] Perhaps changing the value 65536 (64MB of video RAM?) to a smaller value might reproduce the problem faster, and changing the value to a larger value might be a temporary workaround?

I hope that this information is helpful. Let me know what terminal commands you would like me to run in the guest VM or on the host operating system, to help further troubleshoot this bug.

Comment 20 Christophe Fergeau 2015-02-12 17:35:22 UTC

*** Bug 1192154 has been marked as a duplicate of this bug. ***

Comment 21 Christophe Fergeau 2015-02-12 17:37:40 UTC

Bug #1192154 says:

Additional info:
- Upstream commit from http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=3d511c30206bd8c9a207c436186a03af0bb02962 seems to resolve the issue.
- patched version of the driver attached

Comment 22 Christophe Fergeau 2015-02-12 18:00:05 UTC

Would be interested to know if this rpm attached to bug #1192154 helps or not in order to determine whether they should be duplicates or not.

Comment 23 Joe Wright 2015-02-12 18:17:17 UTC

Upstream commit:

Dynamically adjust chunk size to avoid command buffer overflow.
The maximum number of "commands" that can be queued at once is fixed at compile time at MAX_RELOCS. However, during the creation of an image object in qxl_image_create(), the image is split into commands of maximum size 512*512. For a large dual-head system, it is easy to create an image for which the number of chunks will result in an overflow of MAX_RELOCS number of "commands". Identify this scenario and dynamically increase the chunk size to avoid the overflow, and the resulting assert() which crashes Xorg. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=79317

http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=3d511c30206bd8c9a207c436186a03af0bb02962

Comment 24 Pablo Iranzo Gómez 2015-02-13 08:30:07 UTC

(In reply to Christophe Fergeau from comment #22)
> Would be interested to know if this rpm attached to bug #1192154 helps or
> not in order to determine whether they should be duplicates or not.

Proposing that RPM to customer to validate on a third machine to keep clean from other tests.

Comment 25 bugzilla 2015-02-13 13:19:44 UTC

(In reply to Pablo Iranzo Gómez from comment #24)
> (In reply to Christophe Fergeau from comment #22)
> > Would be interested to know if this rpm attached to bug #1192154 helps or
> > not in order to determine whether they should be duplicates or not.
> 
> Proposing that RPM to customer to validate on a third machine to keep clean
> from other tests.

I assume that by "customer", you are referring to me.  Can you please grant me permission to access bug #1192154 and the rpm attached, since when I click on that hyperlink I receive the following error message:

"You are not authorized to access bug #1192154. Most likely the bug has been restricted for internal development processes and we cannot grant access."

An alternative option is to attach that rpm to this bug so that I can download it, however this could cause confusion.  Based on the upstream commit description, I'm not sure that the two bugs are duplicates or that the rpm will solve my problem.  Specifically:
"For a large dual-head system, it is easy to create an image for which the number of chunks will result in an overflow"
I am currently using a laptop with screen resolution 1600x900, no external monitor, so quite the opposite of "a large dual-head system".

Comment 26 Pablo Iranzo Gómez 2015-02-13 13:38:53 UTC

(In reply to bugzilla from comment #25)
> (In reply to Pablo Iranzo Gómez from comment #24)
> > (In reply to Christophe Fergeau from comment #22)
> > > Would be interested to know if this rpm attached to bug #1192154 helps or
> > > not in order to determine whether they should be duplicates or not.
> > 
> > Proposing that RPM to customer to validate on a third machine to keep clean
> > from other tests.
> 
> I assume that by "customer", you are referring to me.  Can you please grant
> me permission to access bug #1192154 and the rpm attached, since when I
> click on that hyperlink I receive the following error message:

By customer I refer to the customer case attached to this bugzilla ticket.

As I'm not the owner of this BZ, neither the other one, I cannot decide if I should or should not make it available outside the scope of a support case.

If you've a support case regarding this issue, feel free to post a private comment so I can check that case number, attach to this BZ for tracking and making the rpm available there, otherwise, BZ asignee should decide if the rpm can be made public or not.

Regards,

Comment 28 bugzilla 2015-02-14 00:51:12 UTC

(In reply to Pablo Iranzo Gómez from comment #26)
> (In reply to bugzilla from comment #25)
> > (In reply to Pablo Iranzo Gómez from comment #24)
> > > (In reply to Christophe Fergeau from comment #22)
> > > > Would be interested to know if this rpm attached to bug #1192154 helps or
> > > > not in order to determine whether they should be duplicates or not.
> > > 
> > > Proposing that RPM to customer to validate on a third machine to keep clean
> > > from other tests.
> > 
> > I assume that by "customer", you are referring to me.  Can you please grant
> > me permission to access bug #1192154 and the rpm attached, since when I
> > click on that hyperlink I receive the following error message:
> 
> By customer I refer to the customer case attached to this bugzilla ticket.
> 
> As I'm not the owner of this BZ, neither the other one, I cannot decide if I
> should or should not make it available outside the scope of a support case.
> 
> If you've a support case regarding this issue, feel free to post a private
> comment so I can check that case number, attach to this BZ for tracking and
> making the rpm available there, otherwise, BZ asignee should decide if the
> rpm can be made public or not.


I am just a home user having paid $179 for a "Red Hat Enterprise Linux Workstation, Self-support" subscription, so I don't (and can't) have a support case regarding this issue.

However, it appears that I am the only person on this discussion thread so far who has been able to repeatedly and reliably reproduce this bug, making me the ideal person to test whether the rpm fixes this bug (and whether the two bugs are duplicates).

Needinfo assignee, to decide whether to let me help test the rpm.

Comment 29 Christophe Fergeau 2015-02-17 13:04:51 UTC

Created attachment 992669 [details]
RPM which was attached to bug #1192154

This is the scratch build that was proposed for testing in bug #1192154. It is the same as the official xorg-x11-drv-qxl-0.1.1-15.el6.x86_64 build with the patch from http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=3d511c30206bd8c9a207c436186a03af0bb02962 added.

Comment 30 Christophe Fergeau 2015-02-18 11:28:27 UTC

(In reply to bugzilla from comment #28)
> Needinfo assignee, to decide whether to let me help test the rpm.

x86_64 RPM has been attached to that bug

Comment 33 bugzilla 2015-02-21 13:51:59 UTC

Thanks Christophe for sharing the RPM so that I can help you test and try to fix this bug.  Unfortunately, the RPM doesn't fix this bug.  Please unmark this bug as a duplicate of bug 1192154.

What is the next step?  Are Red Hat engineers able to reproduce this bug in order to troubleshoot and fix it, or would you like to provide me with a version of the RPM that writes numerous debug messages to a log file to narrow down the cause of the bug?

Here is how I tested the RPM attached to this bug:

I ran the following commands on the GUEST (KVM virtual machine) operating system:

# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i qxl
xorg-x11-drv-qxl-0.1.1-15.el6.x86_64

[I downloaded the RPM attached to this bug, note "jx1" in the filename]

# rpm -U xorg-x11-drv-qxl-0.1.1-15.el6_6.jx1.x86_64.rpm

# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i qxl
xorg-x11-drv-qxl-0.1.1-15.el6_6.jx1.x86_64

[I rebooted the guest VM to ensure that the jx1 version of the RPM is in use]

# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' -a | grep -i qxl
xorg-x11-drv-qxl-0.1.1-15.el6_6.jx1.x86_64

Here is the familiar extract from /var/log/Xorg.0.log.old after I read approximately 150 news articles and X froze and restarted:
[ 19583.579] Out of memory allocating 260588 bytes
[ 19583.579] Out of mem - stats
[ 19583.580] max system bytes =   50319360
[ 19583.580] system bytes     =   50319360
[ 19583.580] in use bytes     =   28734184

Here is the familiar extract from /var/log/Xorg.0.log.old after I read another approximately 150 news articles and X froze and restarted again:
[ 36702.140] Out of memory allocating 261428 bytes
[ 36702.140] Out of mem - stats
[ 36702.142] max system bytes =   50319360
[ 36702.142] system bytes     =   50319360
[ 36702.142] in use bytes     =   29341672

Comment 34 Marc-Andre Lureau 2015-02-23 10:07:52 UTC

(In reply to bugzilla from comment #33)
> Here is the familiar extract from /var/log/Xorg.0.log.old after I read
> approximately 150 news articles and X froze and restarted:

Give a bit more details on how you reproduced. You are using rhel6.6 workstation guest on rhel6.6 host, with 64mb ram/vram. I supposed you didn't modify the desktop or any particular settings and you started firefox, what is its version? what is the webpages you opened and did you do any action except a refresh of the home page? How long it took to reach the crash? 

Thanks for your help

Comment 35 bugzilla 2015-02-28 09:39:38 UTC

(In reply to Marc-Andre Lureau from comment #34)
> (In reply to bugzilla from comment #33)
> > Here is the familiar extract from /var/log/Xorg.0.log.old after I read
> > approximately 150 news articles and X froze and restarted:
> 
> Give a bit more details on how you reproduced. You are using rhel6.6
> workstation guest on rhel6.6 host, with 64mb ram/vram. I supposed you didn't
> modify the desktop or any particular settings

The host OS is a default install of RHEL 6.6 plus qemu.

The guest OS is a default install of RHEL 6.6, with minimal changes to the configuration of Firefox (such as font sizes) plus a few mainstream Firefox plugins such as noscript and adblock.

> and you started firefox, what is its version?

This crash has happened every weekend when I read approximately 150 web pages, ever since RHEL 6.6 was released.  I always keep the host OS and guest OS up to date on patches.  So the answer to your question is "every version of Firefox ESR released since RHEL 6.6 was released."

Firefox ESR 31.5.0 was released a few days ago, so I was using it when Xorg crashed this weekend, resulting in the following extract of the Xorg log file after I read 168 web pages (news articles):
[ 14078.327] Out of memory allocating 258320 bytes
[ 14078.327] Out of mem - stats
[ 14078.330] max system bytes =   50319360
[ 14078.330] system bytes     =   50319360
[ 14078.330] in use bytes     =   31838256

> what is the webpages you opened

The web pages I am reading are a week's worth of news articles, almost exclusively from http://www.zdnet.com/ and http://www.theregister.co.uk/

> and did you do any action except a refresh of the home page?

No, and I didn't even do a refresh of the home page.  I open each news article in a new web browser tab, read the article, then close the web browser tab.  I have a maximum of about 20 web browser tabs open at any time.

> How long it took to reach the crash? 

I speculate that this has nothing to do with how much time elapses after I boot up the guest OS, but rather how long it takes me to read approximately 150 news articles.  Assuming the first column of text in the Xorg log file is the number of seconds elapsed since Xorg began running, my log extracts in this discussion thread indicate how much time elapsed before Xorg crashed.  Specifically, these logs indicate the crash happened after:
* 15205 seconds.
* 23281 seconds.
* 19583 seconds.
* 17119 seconds.
* 14078 seconds.

I tried to identify a simpler way to reproduce the crash, but I only succeeded in identifying actions that don't contribute to the crash.  Specifically:
* opening and closing several hundred blank web browser tabs didn't trigger the crash, and didn't appear to cause the crash to happen sooner.
* visiting the web sites http://www.zdnet.com/ and http://www.theregister.co.uk/ and refreshing these web pages over a hundred times each, didn't trigger the crash, and didn't appear to cause the crash to happen sooner.

I speculate that refreshing an existing web page, and loading blank web browser tabs, doesn't call the buggy function.

Comment 44 Christophe Fergeau 2015-03-24 13:31:28 UTC

Created attachment 1005860 [details]
Test RPM

Found one more leak during investigation of bug #1199355 , see http://lists.freedesktop.org/archives/spice-devel/2015-March/019229.html , hopefully this bug has the same root cause.

Comment 45 Christophe Fergeau 2015-03-24 13:33:05 UTC

Could you try the attached RPM and see if you hit this issue?

Comment 46 Christophe Fergeau 2015-04-01 16:49:32 UTC

Did anyone get a chance to test this build? Since I haven't managed to reproduce it, I cannot check whether this helps with this bug or not.

Comment 47 Tomas Pelka 2015-04-01 19:53:08 UTC

(In reply to Christophe Fergeau from comment #46)
> Did anyone get a chance to test this build? Since I haven't managed to
> reproduce it, I cannot check whether this helps with this bug or not.

Just FYI, spice-qe was not able to reproduce.

Comment 48 bugzilla 2015-04-02 09:48:27 UTC

(In reply to Christophe Fergeau from comment #46)
> Did anyone get a chance to test this build? Since I haven't managed to
> reproduce it, I cannot check whether this helps with this bug or not.

I tried the latest test RPM.  I successfully loaded over 450 news articles (one news article per web page).  I stopped counting after 450.  There was no crash, unlike every previous weekend which crashed after I loaded approximately 150 news articles.
I suggest that you should close this bug ticket.
Thank you.

Comment 49 Christophe Fergeau 2015-04-02 10:13:52 UTC

*** Bug 1170234 has been marked as a duplicate of this bug. ***

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