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):
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...
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.
(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
I have applied this patch to cairo-1.8.2 and it sure does solve (bypass) our problem. Thanks a lot
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.