Strange libXrender behaviour on Solaris10/SPARC

Nicolai Stange nicolai.stange at
Thu Dec 2 09:29:00 PST 2010

Hi everybody,

> Currently available versions of Xnewt are built from the xorg-server 1.3.0
> sources.
I've caught the problem by building a Xvfb and debugging it

The symptoms are as follows: If I run a GTK+-2.20 X-client with
gtk-engines-2.20.1 (clearlooks) enabled or a wxgtk-2.8.11 X-client (with
a gtk configured to use nothing from gtk-engines), with a Xnewt (SRS
4.1/4.2) or Xvfb on the other side, I often, though not always,
get the following:
# /path/to/gtk-2.20.0/bin/gtk-demo --sync
The program 'gtk-demo' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 2307 error_code 2 request_code 147 minor_code 34)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error()

With Xnewt, I tracked it down:
The client sends a XRenderCreateLinearGradient with
(gdb) p/x *stops at 4
$3 = {0x0, 0x8000, 0x8000, 0x10000}

This arrives correctly at Xvfb, but in 
xorg-server- (initGradient), 
    dpos = -1;
    for (i = 0; i < stopCount; ++i) {
        if (stopPoints[i] <= dpos || stopPoints[i] > (1<<16)) {
            *error = BadValue;
        dpos = stopPoints[i];

a BadValue gets returned due to the two subsequent 0x8000-stops.

Note that this problem doesn't occur with a current xorg-server:
xorg-server-1.7.1/render/picture.c:873 (initGradient)
    dpos = -1;
    for (i = 0; i < stopCount; ++i) {
        if (stopPoints[i] < dpos || stopPoints[i] > (1<<16)) {
            *error = BadValue;
        dpos = stopPoints[i];
The le has been replaced by a lt.

Looking at the other xorg-server releases, the same is true for all
releases starting from
I don't know whether has any relevance in current production
systems except for the Xnewt.
Alan, will this issue be fixed in the Xnewt?
If not, I could also live with working around through the libXrender by
never sending two subsequent equal stops (modifying the stops
And then hopefully, I'll finally get a working, good looking and current
GTK on our SRS :)

Best wishes


More information about the xorg mailing list