The link here to the PDF file seems to point at an xorg.conf file. The debian bug's link to the PDF file is broken. So the bug can not be reproduced.

The link to the PDF file was wrong, it should be
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=54;filename=chapter64.pdf;att=1;bug=320627

I can't attach the file here because it is too big (15MB).

I just downloaded the file (a bit slow) and open it with xpdf on Xserver 1.4.0.90 and pixman 0.9.6, it crashed pretty quickly after I played with the scrollbar on the left.

So yes, this bug can still be reproduced very easily.

Crashed my X server too (Gentoo package x11-base/xorg-server-1.3.0.0-r5).

On Thu, Feb 28, 2008 at 05:28:05 -0800, bugzilla-daemon@freedesktop.org wrote:

> --- Comment #3 from Erik <esigra@gmail.com>  2008-02-28 05:28:05 PST ---
> Crashed my X server too (Gentoo package x11-base/xorg-server-1.3.0.0-r5).

Crashes Xephyr too (from server-1.4-branch, as input in master is broken atm):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7bea6b0 (LWP 24322)]
0x080a2c15 in fbPolyline32 (pDrawable=0x8526ae0, pGC=0x84b19e8, mode=0, npt=1, 
    ptsOrig=0xb7383698) at ../../fb/fbbits.h:752
752                             STORE(bits,xor);
(gdb) p *bits
Cannot access memory at address 0xb7979c5c
(gdb) info locals
_pPix = <value optimized out>
pts = (INT32 *) 0xb73836a4
xoff = 9
yoff = -32554
bias = 216
dstStride = 640
dstXoff = <value optimized out>
dstYoff = <value optimized out>
bits = (CARD32 *) 0xb7979c5c
bitsBase = (CARD32 *) 0xb2b2cc2c
xor = 0
and = 0
dashoffset = 0
ul = 2135228416
lr = -2135424881
pt1 = <value optimized out>
pt2 = -2147287032
e = -59973
e1 = 8
e3 = -131064
len = 64836
stepmajor = -640
stepminor = -1
octant = <value optimized out>
(gdb) p *pDrawable
$7 = {type = 0 '\0', class = 1 '\001', depth = 24 '\030', 
  bitsPerPixel = 32 ' ', id = 10485859, x = 9, y = -32554, width = 1216, 
  height = 47988, pScreen = 0x81c2a18, serialNumber = 4275}

The value of pDrawable->y seems broken.

Cheers,
Julien

punting this one, too ...

(In reply to comment #4)
> Crashes Xephyr too (from server-1.4-branch, as input in master is broken atm):

still reproducible with 1.7...

Created attachment 37924 [details] [review]
0001-fb-Fix-overflow-computation-in-lines-arcs-polys-glyp.patch

This patch is better, but not right.  I can still get it to crash at the STORE(bits,xor) in the polyline template if I play with it long enough, although it seems to be a function of the size of the xpdf window (and thus, I suppose, on the scrolling granularity, since larger windows crash which would have finer granularity).

This also exposes an xpdf bug, which is that it tries to do guffaw scrolling far larger than X says you can, but that's just a client bug like any other.

Created attachment 37994 [details] [review]
11503.patch

This one works though.

Ok, I think I understand the issue now (too many numbers). The target window is taller than 32768 pixels, and yet the origin is way above the screen. So, the valid range of coordinates within the window is actually across the 32768 boundary, with some larger than int16 can hold.

The fb code cannot ever draw to coordinates above 32767, even with relative coordinates as those are converted to absolute coordinates before being drawn.

The example provided demonstrates how this breaks down -- a negative 'y' value is within the clip bounds when all are interpreted as int16 values.

It's not the fancy clipping code at fault, just the limited range of the coordinate system.

It should suffice to check for negative incoming coordinates (as those are never valid in any drawable), which is the piece Adam added in his working patch. Alternatively, the clip box could be restricted to values below 32768. Checking for negative coordinates is a whole lot simpler.

This patch should fix the problem, by looking for negative coordinates in the incoming coordinate:

-#define isClipped(c,ul,lr)  ((((c) - (ul)) | ((lr) - (c))) & 0x80008000)
+#define isClipped(c,ul,lr)  (((c) | ((c) - (ul)) | ((lr) - (c))) & 0x80008000)

Created attachment 38018 [details]
Creates window with visible coordinates > 32767 and attempts to draw

Here's a short program which exhibits this bug, crashing the X server without a lot of fussing around. My trivial (reject negative coords) patch resolves this issue.

Ajax reviewed my short patch and it has been merged to master in 3e56efcfb63677cd8574e1e435e61d96f79ea536