[cairo-bugs] [Bug 15628] cairo-1.6.4 testsuite crashes Xserver

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=15628


Carl Worth <cworth at cworth.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Chris Wilson <chris at chris-wilson.co.uk>  2008-10-10 08:46:01 PST ---
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 from Peter Breitenlohner <peb at mppmu.mpg.de>  2008-10-17 05:42:54 PST ---
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 from Carl Worth <cworth at cworth.org>  2008-11-13 08:13:03 PST ---
(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


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.