GNOME Bugzilla – Bug 392853
gnome-settings-daemon unaligned accesses
Last modified: 2007-02-23 22:00:15 UTC
(from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215027) On the ia64 architecture, people are seeing unaligned access messages in their syslogs for gnome-settings-daemon. Program received signal SIGBUS, Bus error.
+ Trace 99404
Thread 2305843009259911824 (LWP 5158)
This is actually a libxklavier bug, but I don't see a component for that in freedesktop bugzilla, so i'm abusing control-center's bugzilla a bit.
Created attachment 79405 [details] [review] This should fix things XChangeProperty has unintuitive semantics. We need to make sure it gets passed the address of a long for card32 values even though long isn't always 32-bit. Sergey, can you commit this?
I am sorry - this fix does not make sense to me. Moreover, it is wrong - on platforms where sizeof gulong != 4. What I am doing is setting 32-bit (!) property on a window. May be, it is a bug in xlib (XChangeProperty function)? Since I do not have ia64, I do not know about its addressing limitations.
Hi Sergey, XChangeProperty has really counter-intuitive semantics in this regard (for historical reasons?). The behavior is documented, though. The man pages says, "If the specified format is 32, the property data must be a long array" I'm fairly confident that the fix is correct, even though the old code _seems_ like it would be more correct.
Well, the thing is that I do not like the code (and fixes) which I do not understand. So please could you explain why does this fix work?
The fix works because XChangeProperty is expecting you to pass it an address to a long (from the man page as mentioned in comment 3) which on some 64-bit architures needs to be 8-byte aligned. If you pass it the address to a CARD32 then it will only be 4-byte aligned. When XChangeProperty tries to dereference the address passed in, it's going to do it as a long which will cause an unaligned access message because the pointer passed in isn't on an 8-byte boundry. I think it boils down to the original author of XChangeProperty assuming long is 32-bit, which is not always the case. The upshot is that XChangeProperty has a weird, counter-intuitive interface. Owen, can you confirm what I'm saying is correct?
If what you're saying is correct, it mean xorg should be fixed (i.e. xlibc), not libxklavier. It's their bug.
Yes, using long for format=32 was a weird and incorrect decision, but it is unfortunately simply how Xlib works at this point. Any change would be API and ABI compatibility. It's not going to happen. You have to make your code work with the Xlib API as it exists.
My guess is that when the Xlib API was being written, there was no autoconf and no C99 stdint.h. So they limited themselves to types defined by the C standard of then, that is, char, short, int, long, with the assumptions that sizeof(char)>=1, sizeof(short)>=2, sizeof(long)>=4. In XRender, it's also assumed that sizeof(int)>=4. The CARD8, CARD16, CARD32 stuff are mostly relevant in the X protocol, not public libraries.
Ok. This solution is questionable, but since it xlib suxx at that point, I'll do it.
Committed. Thanks lads for the discussion and the explanation.