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.
