Re: Strange X11 crashes on 5.0

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I assumed (maybe wrongly) the X network protocol is all in network
> byte order.

Wrongly.  X byte sex on the wire is specified by the client at
connection startup.

> [...] the crash wasn't in visual enumeration (see below).

> I guess my main point is, it's been broken for a really long time.
> My friend was reporting this kind of problem 2 - 3 yrs ago, and word
> everywhere on the street among new kids is ``give up, just use
> Xvnc.''

Gah.  The _right_ answer is "stop trying to run busted code; fix it or
ditch it".  As long as people paper over client-side bugs with kludges
like using Xvnc, client authors will continue writing stupid
assumptions into clients (possibly directly, possibly through use of
misdesigned and/or misimplemented libraries).

> Core was generated by `gtk-demo'. Program
> terminated with signal 10, Bus error.
> #0  0x000000004130a168 in XListInputDevices (dpy=0x45009000,
>     ndevices=0xffffffffffffafac) at XListDev.c:180
> 180                         B->class = ButtonClass;

This appears to be part of an extension I do not really know.  However,
the X I do have (X11R6.4p3) does have an XListDev.c which does have a
line with that text near, but not quite at, line 180, inside a function
named XListInputDevices - presumably a different version of the code.

Based on reading that code, the bug here quite probably *is* in X.
While I can't be sure without reading the code for the library actually
used in your case, the code I do have plays fast and loose with types,
making assumptions C has never promised but which historically most
systems have let code get away with making.  (It is hardly alone in
this; I refuse to use Xt or Xt-based code because it had, and
presumably still has, similar busted code.)

My guess is that it doesn't crash on 64-bit peecees because they are
misalignment-tolerant, doesn't crash on 32-bit arches because
everything ends up happening to be correctly aligned, and doesn't crash
with Xvnc because Xvnc either does not support this extension or does
not present to its clients the input device the real server does which
is tickling the bug.

In this case, the broken code is in XListInputDevices.  In particular,
if there is a ValuatorClass device with an odd number of axes, then, on
a sparc64 with the usual compilers, the next device after that (if such
a "next device" exists) will attempt to access 64-bit data at addresses
that are odd multiples of 4.  This is probably what's going wrong here,
and it quite definitely is a bug in the implementation of
XListInputDevices; it is making assumptions about alignment for which
there is no justification in C - basically, that a malloc()ed pointer
can be advanced by sizeof() one struct and still be correctly aligned
for storing a completely unrelated struct.

At least, that's what the code I have does.  I am, strictly, guessing
when I say that that's probably what's responsible for the crash you
see, but I feel reasonably confident making that guess.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B