Strange libXrender behaviour on Solaris10/SPARC

[Nicolai Stange]

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 1.3.0.0 and debugging it
there.

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 1.3.0.0 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()
function.)

With Xnewt 1.3.0.0, 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-1.3.0.0/render/picture.c:954 (initGradient), 
    dpos = -1;
    for (i = 0; i < stopCount; ++i) {
        if (stopPoints[i] <= dpos || stopPoints[i] > (1<<16)) {
            *error = BadValue;
            return;
        }
        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;
            return;
        }
        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 1.3.99.0
I don't know whether 1.3.0.0 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
slightly). 
And then hopefully, I'll finally get a working, good looking and current
GTK on our SRS :)

Best wishes

Nicolai