GNOME Bugzilla – Bug 114035
Wrong window sizes on Alpha, AMD64 architecture
Last modified: 2004-12-22 21:47:04 UTC
This is using CVS HEAD built with jhbuild. Happens with both gcc-2.95 and 3.0. Most windows are very large. A lot can't be resized for some reason. The ones that I can resize show very strange sizes in the geometry box. Values such as -570 x 987653656 are common. Nautilus windows seem be have normal size as well. Also konsole (KDE terminal) seems to work ok. All other terminals and most Gnome2 applications display this behaviour. Looking through the metacity log file I see things like this which look suspicious: GEOMETRY: Updating WM_NORMAL_HINTS for 0x1800009 (Terminal) GEOMETRY: Window 0x1800009 (Terminal) sets base size 1707 x 11946 GEOMETRY: Window 0x1800009 (Terminal) sets min size 15 x 1088604321 GEOMETRY: Window 0x1800009 (Terminal) sets resize width inc: 29952 height inc: 6144 GEOMETRY: Window 0x1800009 (Terminal) sets gravity 0
Created attachment 16989 [details] Metacity logfile
Note, I had to shorten the logfile since bugzilla failed when I tried to upload the entire logfile. It should still contain the things I find suspicious.
does "PWS" mean anything significant? Metacity stable branch is known to work on 64-bit (I just fixed a startup bug on big-endian 64-bit, but it was already working fine on little) HEAD may have some 64-bit issues as I don't know if it's been tested. Hard for anyone to debug though, unless they have a 64-bit system.
PWS = Personal WorkStation, I doubt it matters, though I don't know all that much about the Alpha architecture. I will poke through the source code and see if I can find anything.
xprops.c:size_hints_from_results() looks like it might come out badly. Adding some debug printf in there might help.
In a lot of places we cast an array of longs to an array of chars before passing it to XChangeProperty (and presumably do the reverse when we receive a PropertyNotify). To me that seems horribly broken, endian-wise. If different clients are running on different architectures this seems like it would cause very bad things to happen. Is there some standard byte-order we should be using here? Or is there some black magic happening here that I don't know about?
The X server knows the endianness of the client, and swaps bytes on the server side if required. There's some horrible confusion in Xlib where it sometimes expects "long" for something that ends up as a CARD32 on the server side. I can never remember the details of that though.
Adding lines like this: printf("JBM: min_width -> raw: %d, conv: %d\n", raw->minWidth, hints->min_width); to size_hints_from_results() gives this sort of output: JBM: min_width -> raw: 1, conv: 1 JBM: min_height -> raw: 3, conv: 3 JBM: max_width -> raw: 0, conv: 0 JBM: max_height -> raw: 160, conv: 160 JBM: width_inc -> raw: 1953654016, conv: 1953654016 JBM: height_inc -> raw: 1701407856, conv: 1953654016 JBM: min_width -> raw: 1, conv: 1 JBM: min_height -> raw: 512, conv: 512 JBM: max_width -> raw: 1, conv: 1 JBM: max_height -> raw: 512, conv: 512 JBM: width_inc -> raw: 12244224, conv: 12244224 JBM: height_inc -> raw: 96, conv: 12244224 JBM: min_width -> raw: 13, conv: 13 JBM: min_height -> raw: 0, conv: 0 JBM: max_width -> raw: 0, conv: 0 JBM: max_height -> raw: 4, conv: 4 JBM: width_inc -> raw: 0, conv: 0 JBM: height_inc -> raw: 12244344, conv: 0 This is from starting Gnome, starting an xterm, exiting xterm and killing X. Not sure if the modifiers are correct though.
I think raw should use "%ld" rather than "%d" (the compiler should print warnings if this is wrong)
Results from using %ld for raw. JBM: min_width -> raw: -4611686018427387903, conv: 1 JBM: min_height -> raw: 3, conv: 3 JBM: max_width -> raw: 0, conv: 0 JBM: max_height -> raw: 160, conv: 160 JBM: width_inc -> raw: 7309940851192521984, conv: 1953654016 JBM: height_inc -> raw: 7955925896721427568, conv: 1953654016 JBM: min_width -> raw: 45675293565779969, conv: 1 JBM: min_height -> raw: 2314183217227235840, conv: 512 JBM: max_width -> raw: 72709329555292161, conv: 1 JBM: max_height -> raw: 2314183217227235840, conv: 512 JBM: width_inc -> raw: 2199035499776, conv: 12244224 JBM: height_inc -> raw: 96, conv: 12244224 JBM: min_width -> raw: 13, conv: 13 JBM: min_height -> raw: 0, conv: 0 JBM: max_width -> raw: 17179869184, conv: 0 JBM: max_height -> raw: 4, conv: 4 JBM: width_inc -> raw: 0, conv: 0 JBM: height_inc -> raw: 2199035499896, conv: 0
Oh, this may be really dumb - see the line: #if defined(WORD64) && defined(UNSIGNEDBITFIELDS) Try changing that line to "#if 1" and see what happens.
It gives the same numbers, funnily enough I get the same if I change it to #if 0 as well.
Just built garnome 0.25.1 (2.5.2) and it exhibits the same problem. Going back to 2.4.55 makes it work correctly.
Still seeing this in 2.6.1?
yes, no change. Built with garnome 0.27.1.
I think I see the problem. compare async-props.c:async_get_property_handler() to lib/X11/GetProp.c:XGetWindowProperty() in Xlib. Xlib does the bizarre thing where XGetWindowProperty returns an array of long if you ask for format 32. So format 32 may return an array of 64-bit values. the metacity async property stuff always returns an array of 32-bit values. But metacity-Xatomtype.h defines all the structs as blocks of long, not as blocks of 32-bit integers. Should make async_get_property_handler match the XGetWindowProperty semantics (they're broken, but we use XGetWindowProperty elsewhere and it will be too confusing to have two different ways to do it).
Bug #108926 has a patch for this, which I haven't reviewed yet.
I committed a slightly different patch to cvs (with a hack to avoid the extra malloc/copy when possible). But should fix - please test and advise.
Changing summary.. Gwenole, could you test havoc patch (from CVS) on AMD64 system ?
closing bug since we have no reason to believe that this is still a problem.
Yes, it works correctly now on Alpha. Thanks a lot, now I can run the development version again.