Bug 43361
| Summary: | unaligned accesses in g_render.c | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | Michal Jaegermann <michal> |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | alpha | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-07-18 13:58:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Mesa 3.4.2 is what should be used with XFree86 4.1.0. No public packages are available yet but they are built. The code in question actually comes from XFree and if binaries will suffer from alignment problems, or not, likely depends on a luck. Also spec file for XFree86-4.0.3-18 (yes, I know that this is not public as well) says: %define MesaPackageDep 3.4.1-1 Should this requirement considered to be overdone a bit? I have no idea how to fix that stuff. If you can send me a patch, I'll send
it upstream though. As for the Mesa dependancy it is _critical_.
Our Mesa package includes XFree86 fragments taken from the XFree86 packaging,
and there is a chicken and egg scenario when building them. Mesa and X not
being in sync totally screws DRI. I am currently assimilating Mesa completely
inside the XFree86 packaging which will force Mesa and X to be in sync at
all times. The new Mesa subpackages will be called XFree86-Mesa,
XFree86-Mesa-devel, XFree86-Mesa-demos, and will be dependant on the main
XFree86 package, etc.. They will have a "provides Mesa", etc..
When that happens, the MesaPackageDep will disappear and be replaced by
Requires: XFree86-Mesa = %{version}-%{release}
Any bumps will be ironed out in time..
Realistically the unaligned traps won't be fixed unless someone sends me
a patch, or waits until I have time to look into it (without the hardware).
I've submitted this bug report upstream, and will track it. Problem was fixed upstream. Fix is in my QUEUE. Fixed in current 4.1.0-3 release, has been fixed for a while, but didn't close bug report.... |
Description of Problem: The problem manifests itself in Mesa but this is really g_render.c trouble so it belongs to X. Various programs from "Mesa-demos" are consistently getting on Alpha a number of "unaligned trap" errors. Like this: cubemap(16472): unaligned trap at 0000020000590334: 000002000002a03c 27 2 cubemap(16472): unaligned trap at 0000020000590344: 000002000002a044 27 3 cubemap(16472): unaligned trap at 0000020000590348: 000002000002a04c 27 4 cubemap(16472): unaligned trap at 0000020000590350: 000002000002a054 27 5 With Mesa-3.4.1 recompiled for debugging and run from a shell which forces SIGBUS, instead of a fixup, on an unaligned trap 'gdb' reveals this: Starting program: /usr/bin/gears Program received signal SIGBUS, Bus error. __indirect_glFrustum (left=-1, right=1, bottom=-1, top=1, zNear=5, zFar=60) at g_render.c:2523 2523 __GLX_PUT_DOUBLE(12,right); Starting program: /usr/bin/bounce Program received signal SIGBUS, Bus error. __indirect_glOrtho (left=-8.0000002384185791, right=8.0000002384185791, bottom=-6, top=6, zNear=-6, zFar=6) at g_render.c:2590 2590 __GLX_PUT_DOUBLE(12,right); Starting program: /usr/bin/gamma Program received signal SIGBUS, Bus error. __indirect_glOrtho (left=-1, right=1, bottom=-1, top=1, zNear=-1, zFar=1) at g_render.c:2590 2590 __GLX_PUT_DOUBLE(12,right); Starting program: /usr/bin/cubemap GL_REFLECTION_MAP_ARB mode keys: SPACE - toggle animation CURSOR KEYS - rotation m - toggle texgen reflection mode Program received signal SIGBUS, Bus error. __indirect_glFrustum (left=-2, right=2, bottom=-2, top=2, zNear=6, zFar=20) at g_render.c:2523 2523 __GLX_PUT_DOUBLE(12,right); This is a backtrace for 'bounce' #0 __indirect_glOrtho (left=-8.0000002384185791, right=8.0000002384185791, bottom=-6, top=6, zNear=-6, zFar=6) at g_render.c:2590 #1 0x20000412588 in glOrtho (left=-8.0000002384185791, right=8.0000002384185791, bottom=-6, top=6, nearval=-6, farval=6) at glapitemp.h:938 #2 0x120001a8c in reshape (width=5889, height=172080) at bounce.c:92 #3 0x200001409f8 in processWindowWorkList (window=0x120105170) at glut_event.c:1193 #4 0x20000140cc8 in __glutProcessWindowWorkLists () at glut_event.c:1328 #5 0x20000140d74 in glutMainLoop () at glut_event.c:1349 #6 0x120002240 in main (argc=1, argv=0x11ffff7b8) at bounce.c:218 and this is for 'cubemap'. #0 __indirect_glFrustum (left=-2, right=2, bottom=-2, top=2, zNear=6, zFar=20) at g_render.c:2523 #1 0x2000040fc08 in glFrustum (left=-2, right=2, bottom=-2, top=2, nearval=6, farval=20) at glapitemp.h:513 #2 0x1200017a8 in reshape (width=300, height=300) at cubemap.c:144 #3 0x200001409f8 in processWindowWorkList (window=0x120104b40) at glut_event.c:1193 #4 0x20000140cc8 in __glutProcessWindowWorkLists () at glut_event.c:1328 #5 0x20000140d74 in glutMainLoop () at glut_event.c:1349 #6 0x120001cfc in main (argc=5889, argv=0x2000002a030) at cubemap.c:248 And this is the code in question, from __indirect_glFrustum, after macros were expanded: *((INT16 *) (pc + 0 )) = 52 ; *((INT16 *) (pc + 2 )) = 175 ; *((FLOAT64 *) (pc + 4 )) = left ; *((FLOAT64 *) (pc + 12 )) = right ; *((FLOAT64 *) (pc + 20 )) = bottom ; *((FLOAT64 *) (pc + 28 )) = top ; *((FLOAT64 *) (pc + 36 )) = zNear ; *((FLOAT64 *) (pc + 44 )) = zFar ; Unaligned access can be silent elsewhere but it is a performance drag on any architecture. Michal michal