Alignment issue on x86_64?

[Andrew Haley]

Rémi Cardona wrote:
> Hi all,
> 
> I've spent several days trying to figure out why a program would send
> wrong values to an Xlib call (gcc version 4.3.1, ld 2.18 but I've
> reproduced with 4.2.4).
> 
> In a nutshell, here's the problem :
> 
> void *utils_atom_get_property(
>         Display *dpy, Window win, Atom to_get, Atom type, unsigned int
> *size)
> {
>         unsigned char *retval;
>         Atom  type_ret;
>         unsigned long  bytes_after, num_ret;
>         long length;
>         int  format_ret;
>         void *data;
>         int ok;
> 
>         retval = NULL;
>         length = 0x7fffffff;
>         ok = XGetWindowProperty(
>                 dpy, win, to_get, 0L, length, False, type, &type_ret,
>                 &format_ret, &num_ret, &bytes_after, &retval);
> ...
> 
> 
> The problem is with the "type" parameter. When utils_atom_get_property
> is called with type=137 :
>  - if I break inside that function, "type" is correctly set to 137
>  - but if I break inside XGetWindowProperty, "type" changes completely
> and seems to take some of the bytes of the adjacent parameter
> (0x7fff00000089,  when "size" is 0x7fff379c7704, the coincidence is just
> too big IMHO).

Or it may be that gdb is misleading you.

How do you know that the parameters to this call are wrong?

> Out of sheer frustration, I just shuffled the declarations at the top of
> the function and it "solved" my bug. Here's the patch I applied to my
> own code (no other changes, just moving the order of the declarations):
> 
> @@ -41,11 +41,11 @@ static int atom_size(int format)
>  void *utils_atom_get_property(
>         Display *dpy, Window win, Atom to_get, Atom type, unsigned int
> *size)
>  {
> -       unsigned char *retval;
>         Atom  type_ret;
> -       unsigned long  bytes_after, num_ret;
> -       long length;
>         int  format_ret;
> +       long length;
> +       unsigned char *retval;
> +       unsigned long  bytes_after, num_ret;
>         void *data;
>         int ok;
> 
> 
> I tried reducing my program to a simpler test case, but it's not as
> trivial. Am I looking at a GCC bug? What can I do to further track it
> down? 

It may be a gcc bug.

The .i file after preprocessing would help.  Use -save-temps to get it.

Are you using -Wall ?

Andrew.