Bug 88519 - Unaligned access in _XimLocalFilter
Summary: Unaligned access in _XimLocalFilter
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: X.Org (show other bugs)
Version: Stable Snapshot 2
Hardware: Other All
: P4 - Low : Normal
Target Milestone: ---
Assignee: Matthias Hopf
QA Contact: Stefan Dirsch
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-09 14:15 UTC by Andreas Schwab
Modified: 2007-06-22 15:17 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schwab 2005-06-09 14:15:05 UTC 
xterm(19641): unaligned access to 0x2000000000f99696, ip=0x2000000000f23841 
xterm(19641): unaligned access to 0x2000000000f9969a, ip=0x2000000000f23850 
xterm(19641): unaligned access to 0x2000000000f9969e, ip=0x2000000000f238e1 
xterm(19641): unaligned access to 0x2000000000f9968e, ip=0x2000000000f23870
Comment 1 Stefan Dirsch 2005-06-09 14:41:16 UTC 
Hmm ... which platform? How to reproduce? Does xterm come up?
Comment 2 Andreas Schwab 2005-06-09 14:43:53 UTC 
Apparently ic->private.local.context is unaligned.
Comment 3 Andreas Schwab 2005-06-09 14:44:32 UTC 
Try samarium.
Comment 4 Matthias Hopf 2006-03-22 16:13:55 UTC 
Currently there are much more pressing issues. Reducing priority, but leaving assigned so it doesn't get lost.
Comment 5 Matthias Hopf 2006-08-16 15:32:54 UTC 
Hm - does this still happen?

struct _XicLocalPrivateRec:
+0   long value_mask   (64bit)
+8   DefTreeBase base  (4x64bit,8x32bit)
+72  DTIndex context   (32bit)

This was a pointer before, so this definitively changed with the Compose cache changes.

It was before:

struct _XicLocalPrivateRec:
+0   long value_mask   (64bit)
+8   DefTree *context  (64bit)

so I don't know how this could ever be unaligned...
I recently fixed an alignment issue, but hasn't been related to .context.

Closing as FIXED, please reopen if this is still an issue. Note that currently STABLE doesn't have any global compose caches yet (the code is there, but the caches aren't). You can force the creation and usage of personalized caches by mkdir .compose-cache in your home.