| Summary: | cfbtile32.c on Sparc causes memory corruption when used with cfb32 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Chris Gilbert <chris> |
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | high | CC: | alan.coopersmith |
| Version: | git | ||
| Hardware: | SPARC | ||
| OS: | NetBSD | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
I don't know that it matters any more (I think all drivers in the Xorg tree have now been converted from cfb to fb), but for what it's worth, the Xsun we ship in Solaris uses 'nlwMiddle >>= 3' there, and has for over a decade. (It only supports 32-bit mode though.) It was actually changed from 3 to PWSH + 1 when Xsun moved from X11R5 to X11R6, but quickly changed back when it found that caused Netscape to crash Xsun. Unfortunately it looks like the fix never got propogated back upstream to the old X Consortium. So... if the fix is known, how about checking it into CVS? ;o) Ping! Any fix in the pipe? Any update on this being checked in/fixed? It's over a year old and the patch is available. Thanks, Chris Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. cfb32 unexists now, so I'm happy to call this fixed. |
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.
cfbtile32.c contains the macro expand, which on sparc does some loop unrolling. When using cfb32, in 32bit mode, PWSH is 0, while PGZB is 4, this causes the following code: # define Expand(left,right) {\ int part = nlwMiddle & ((PGSZB*2)-1); \ nlwMiddle >>= PWSH + 1; \ To become: # define Expand(left,right) {\ int part = nlwMiddle & (7); \ nlwMiddle >>= 1; \ This causes a problem as the the loop following has unrolled the loop 8 times. This causes memory corruption as the loop runs *4 iterations more than it should. The fix is probably to hardcode the numbers to allow for the 8 unroll iterations, as the loop has nothing to do with pixels per a word. However I'm not sure what effect that would have on a 64bit version of the X server. The fix is in the NetBSD tree: http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/xfree/xc/programs/Xserver/cfb/cfbtile32.c.diff?r1=1.1&r2=1.2&f=h Thanks