| Summary: | Xserver 1.3 crash in fbPolyline() when using xpdf | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Brice Goglin <brice.goglin> | ||||||||
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | CC: | esigra | ||||||||
| Version: | 7.2 (2007.02) | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320627 | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 27592 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Brice Goglin
2007-07-09 00:52:24 UTC
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 |
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.