Julien Cristau writes: > > On Sun, Oct 30, 2011 at 20:02:43 -0500, pac...@kosh.dhis.org wrote: > > > Disable "dri" > > Disable "dri2" > > Any particular reason you're doing this?
Because I've read the security document[1]. There's a lot of scary stuff in there. [1] http://dri.sourceforge.net/doc/security_low_level.html > > Is the bug reproducible when using EXA instead of XAA (enabling DRI > should do that, I think, or using the AccelMethod option in the Device > section). The drawing bug occurs with any of these: Option "NoAccel" "true" Option "AccelMethod" "XAA" Option "AccelMethod" "EXA" And it did appear from the log that those options were effective. Still no server crashes in any case. I got a few more clues though, after studying xli expecting to find the cause there, I'm now back to thinking this is a server-side bug. Here are the ingredients required to reproduce the drawing bug: 1. must use XShmPutImage 2. the XImage must be in XYBitmap format 3. the PutImage width must be less than the full width of the XImage The third condition occurs when I press '>' on the xli window, because the resizing of the window generates multiple expose events and xli does with multiple XShmPutImage requests. By hacking xli to always paint a width that is one less than the exposed area's width, I got a test case that demonstrates the bug non-interactively. And it shows the bug even on Xvfb, so this seems to be a core Xserver bug, not a driver thing. I'll work on replacing the hacked xli with a standalone demo. -- Alan Curry -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111101033523.26675.qm...@kosh.dhis.org
