Bug 3794

Summary: potential unaligned memory access in render.c on 64 bits architectures
Product: xorg Reporter: Matthieu Herrb <matthieu.herrb>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high    
Version: git   
Hardware: Other   
OS: OpenBSD   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 1690    
Attachments:
Description Flags
Here's the patch used in OpenBSD none

Description Matthieu Herrb 2005-07-16 07:24:07 UTC
The render code in the X server appears to crash pretty often on OpenBSD/sparc64. 
Running firefox on http://www.conrad.de/ seems to be especially efficient to
trigger the problem about 90% of the time. 
Simon Kellner found it to be caused by an unaligned memory access, when copying
from a data buffer to a long.
Comment 1 Matthieu Herrb 2005-07-16 07:25:03 UTC
Created attachment 3095 [details]
xorg.0.log with VESA driver, 6.8.99.15
Comment 2 Matthieu Herrb 2005-07-16 07:25:54 UTC
mention render in the summary
Comment 3 Michael Lorenz 2005-08-10 06:47:09 UTC
Created attachment 3313 [details] [review]
xkbdesc-ibr-kz-20050918-1643.diff

For the records - I've independently found the same bug in XFree86 4.5 under   
NetBSD/sparc64.   
The problem seems to be that GlyphSet and a few other types are defined as   
unsigned long but the code in render.c assumes sizeof(GlyphSet)==4 which leads 
 
to unaligned accesses sooner or later. They should probably be CARD32 instead, 
 
or something else that's guaranteed to be 32bit. Our fix is slightly different
though.
Comment 4 Daniel Stone 2005-08-28 06:01:51 UTC
mathieu, could you please reattach so I can apply?  got lost in the disk crash.
Comment 5 Matthieu Herrb 2005-08-28 06:42:25 UTC
Created attachment 3074 [details] [review]
Here's the patch used in OpenBSD
Comment 6 Adam Jackson 2005-08-28 12:47:55 UTC
applied to head, thanks!

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.