>>>>> "dm" == der Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:
>>>>> "ef" == Erik Fair <fair%netbsd.org@localhost> writes:
dm> That is (almost) certainly a bug in the app, not a bug in X.
dm> [...] is it different arch, or different endianness, or
dm> unexpected pixmap formats, or localhost versus networked,
both broken case and working case were networked. I assumed (maybe
wrongly) the X network protocol is all in network byte order. This
would mean changing the X server's endyness or LP64ness should be
totally invisible to the app.
Yeah I guess it's possible the sparc64 server (app crashes) lacked a
truecolor visual and the sparc server (app works) had a truecolor
visual, but that'd not be my first guess. and 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.''
ef> the X window server should be robust against malformed
ef> requests, as any graphics protocol (or API) should be. Just as
ef> a userland program shouldn't be able to crash the kernel,
ef> neither should an X application be able to crash the window
ef> server.
OP reported it was the app that crashed, not the X server:
-----8<-----
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;
-----8<-----
Attachment:
pgpFmqghjkyy5.pgp
Description: PGP signature