Bug 15628 - cairo-1.6.4 testsuite crashes Xserver
cairo-1.6.4 testsuite crashes Xserver
Status: RESOLVED FIXED
Product: cairo
Classification: Unclassified
Component: general
1.6.4
x86 (IA32) Linux (All)
: highest blocker
Assigned To: Carl Worth
cairo-bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-21 07:08 UTC by Peter Breitenlohner
Modified: 2008-11-14 02:46 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Breitenlohner 2008-04-21 07:08:17 UTC
When running the cairo-1.6.4 testsuite ("make check") I reproducibly get a crash of the Xserver (Xorg-6.9, linux-2.6.20 on i686).

With the radeon driver (RV370 5B60 [Radeon X300 (PCIE)]) X was using 100% CPU time, and could be killed, but the graphic state was messed up such that a reboot was required.

With the mag driver from Matrox (MGA G550 AGP) X kills itself via xf86SigHandler
and gets automatically restarted from xdm.

All that seems to happen during "TESTING extend-reflect" and the last output I see is in the "make.log" is:

extend-reflect-xlib-fallback-rgb24 [0] (similar):
Comment 1 Chris Wilson 2008-10-10 08:46:01 UTC
That test was disabled for a long time because it hit bugs in drivers (which of course meant nobody was motivated to fix those drivers, nor were we actually checking for bugs in cairo). However, as a known bug cairo does try to avoid triggering it by disabling REPEAT for certain versions of the Xserver - and I believe a few distributors even forced the workaround as it was difficult to correctly identify all affected versions.

It sounds like cairo did not correctly disable sending REPEAT to your Xservers, is that still an issue? I can remember a flurry of mails trying to narrow down the affected versions, but I can't recall if it was before or after 1.6...
Comment 2 Peter Breitenlohner 2008-10-17 05:42:54 UTC
First, please excuse the delay in answering, but we where in the middle of upgrading our (80+) systems from Xorg-6.9 to Xorg-7.3 (plus some newer video drivers). Right now only 8 systems still use Xorg-6.9, all with ATI RS482 [Radeon Xpress 200] chip sets -- these are mishandled by the Xorg-7.3 driver.

Today I ran "make check" for cairo-1.8.0 on three different systems (details one them are below).

The bad news: on CPU 1 with the Xorg-6.9 server the check still causes the Xserver to hang (remote login, killing X, and switching VT don't work: one has to switch off the power).

The good news: om CPUs 2 and 3 with the Xorg-7.3 server the check now succeeds on the systems where it used to crash or hang the Xserver.

The details:

CPU 1: AMD Athlon 64 X2, linux-2.6.23.1-x86_64, xorg-server from Xorg-6.9 (32bit), radeon driver 4.0.3, chip set ATI RS482 [Radeon Xpress 200]

CPU 2: AMD Dual Core Opteron, linux-2.6.23.1-i686, xorg-server-1.4.0, radeon driver 4.3.0 (xf86-video-ati-6.9.0), chip set ATI Radeon X300 (RV370) 5B60

CPU 3: Intel P4, linux-2.6.23.1-i686, xorg-server-1.4.0, nv driver 2.1.12 (xf86-video-nv-2.1.12), chip set nVidia Quadro NVS 55/280

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

Two additional remarks:

1. "make check" produces lots of "FAIL" results (most, but not all, of them from the xlib backend). This is somewhat against the spirit of a testsuite, that either clearly succeeds, or fails which indicates a serious problem.

2. Compiling cairo-1.8.0 with gcc-3.4.6 produces plenty of warnings, most of the "missing initializer". I'd suggest to supply the missing initializer components in order to get rid of these warnings.
Comment 3 Carl Worth 2008-11-13 08:13:03 UTC
(In reply to comment #2)
> The bad news: on CPU 1 with the Xorg-6.9 server the check still causes the
> Xserver to hang (remote login, killing X, and switching VT don't work: one has
> to switch off the power).

Ouch. That's a fairly nasty bug. We thought we had things characterized to avoid this.

I've pasted a patch below which attempts to fix this, and I've got something similar queued up for 1.8.4.

I think this should fix the problem, so I'll proactively mark the bug as resolved. Please reopen it if you test and find that it doesn't work.

-Carl

diff --git a/src/cairo-xlib-display.c b/src/cairo-xlib-display.c
index 5e6dba1..d0a401b 100644
--- a/src/cairo-xlib-display.c
+++ b/src/cairo-xlib-display.c
@@ -291,7 +291,7 @@ _cairo_xlib_display_get (Display *dpy)
 	 * test to known bad releases. But there could be a problem
 	 * again in the future if X.Org server versions ever climb
 	 * back up to 6.7 or 6.8. */
-	if (VendorRelease (dpy) >= 60700000 && VendorRelease (dpy) <= 60802000)
+	if (VendorRelease (dpy) >= 60700000 && VendorRelease (dpy) <= 70000000)
 	    display->buggy_repeat = TRUE;
 
 	/* But even the new modular server has bugs, (bad enough to
Comment 4 Peter Breitenlohner 2008-11-14 02:46:59 UTC
I have applied this patch to cairo-1.8.2 and it sure does solve (bypass) our problem.

Thanks a lot