retitle 216933 xlibs: many clients get BadLength error from X_ChangeProperty request tag 216933 + moreinfo thanks On Tue, Oct 21, 2003 at 03:46:19PM -0400, Joey Hess wrote: > This is the problem I mentioned on irc. For the past week, plus or > minus, X will once or twice a day hose itself. Then simple X programs > all fail to run with the same problem: > > joey@dragon:~>xterm > X Error of failed request: BadLength (poly request too large or internal Xlib length error) > Major opcode of failed request: 18 (X_ChangeProperty) > Serial number of failed request: 51 > Current serial number in output stream: 54 > zsh: exit 1 xterm > > Even restarting X does not seem to help; xdm then goes into a tight loop > of starting, dying before the greeter is shown, etc. I have to reboot to > clear the problem up. Running X programs also eventually die, when they > try to do whatever it is that causes the problem. This includes bringing > up a menu in mozilla-firebird, and xchat seems to just die of its own > accord soon after the problem starts. > > I also tried starting a second X session, while X was hosed on :0.0. > startx -- :2 brought up X, and was able to launch my window manager > (ion-devel), but was unable to run any apps in the window manager. Attempts > to run an xterm resulted in the same error message back at the console. > Similarly, manually running X :2 and then an xterm on that display > failed. This problem description blows my mind. No matter how hosed the X server on :0 (or :1) is, the different instance at :2 should not be affected. Unless it's a bug in the source code. But then why don't you see this problem from the beginning? > ltrace shows the following, and it dies in the same place for other apps > such as xterm: > > joey@dragon:~/tmp/xlogo>ltrace xlogo -sync > __libc_start_main(0x08048e60, 2, 0xbffff8e4, 0x080496b0, 0x08049710 <unfinished ...> > XtOpenApplication(0xbffff88c, 0x08049834, 0x0804a00c, 1, 0xbffff8a0) = 0x08055118 > XtAddCallback(0x08055118, 0x0804a75d, 0x08048da0, 0, 0xbffff8a0) = 1 > XtAddCallback(0x08055118, 0x0804a686, 0x08048d70, 0, 0xbffff8a0) = 1 > XtWidgetToApplicationContext(0x08055118, 0x0804a686, 0x08048d70, 0, 0xbffff8a0) = 0x0804d090 > XtAppAddActions(0x0804d090, 0x0804a01c, 1, 0, 0xbffff8a0) = 0 > XtParseTranslationTable(0x0804983a, 0x0804a01c, 1, 0, 0xbffff8a0) = 0x08055af0 > XtOverrideTranslations(0x08055118, 0x08055af0, 1, 0, 0xbffff8a0) = 0 > XtCreateManagedWidget(0x08049858, 0x0804a080, 0x08055118, 0, 0) = 0x08056f78 > XtRealizeWidget(0x08055118, 0x0804a080, 0x08055118, 0, 0X Error of failed request: BadLength (poly request too large or internal Xlib length error) > Major opcode of failed request: 18 (X_ChangeProperty) > Serial number of failed request: 31 > Current serial number in output stream: 32 > <unfinished ...> > +++ exited (status 1) +++ > > I have attached strace output of xlogo -sync to this bug report. > > Using the xlogo you built w/ debugging symbols, and xlibs-dbg, I was able to > get a backtrace near the failure when running xlogo -sync. I attach a complete > log of that gdb run, but the essence of it is this: Can you please install libxaw7-dbg and get a backtrace with that? I want to see the backtrace on those stack frames. Of course, that may be a red herring, as you say non-Athena apps are effected. -- G. Branden Robinson | A celibate clergy is an especially Debian GNU/Linux | good idea, because it tends to branden@debian.org | suppress any hereditary propensity http://people.debian.org/~branden/ | toward fanaticism. -- Carl Sagan
Attachment:
signature.asc
Description: Digital signature