fatal error: request code=138, error code=129

[mxmilkiib]

On trying to start adwm, error is;

parse.c parsekey():491 Failed to parse symbol from '4096' adwm: fatal error: request code=138, error code=129 X Error of failed request: 129 Major opcode of failed request: 138 (XFIXES) Minor opcode of failed request: 31 () Value in failed request: 0x1 Serial number of failed request: 342 Current serial number in output stream: 361

[bbidulock]

I suppose you are using the default configuration files. I haven't used them in a long time: there is probably a syntax error in the keys file that it doesn't like. I will strap in my config files for the default and see if the problem goes away.

[mxmilkiib]

i tried commenting out all of / renaming the keysrc file, no change.

here's an strace with and without a keysrc

with it, there is an attempt to open XKeysymDB (which doesn't exist) just before the error, not sure if that would cause it though as the trace without doesn't ends the same, or maybe there are two issues.

open("/usr/share/X11/XKeysymDB", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "parse.c parsekey():491 ", 23parse.c parsekey():491 ) = 23 write(2, "Failed to parse symbol from '409"..., 35Failed to parse symbol from '4096' ) = 35

[bbidulock]

Are you running the 0.5.6 release? I know there were some changes to key parsing between 0.5.5 and 0.5.6: in 0.5.5 it was clobbering memory that didn't cause a problem on some architectures some times.

XKeysymDB doesn't exist on my box either.

[bbidulock]

I think you are running an older version, because there is no print on line 491 of parse.c in release 0.5.6. Try running the current git version.

[mxmilkiib]

Ah, apologies, I forgot I switched from adwm-git to adwm yesterday when checking. No parse.c message, but the fatal error is the same with adwm-git (0.6.5.2). Running on Arch Linux x86-64. strace.

[bbidulock]

Oh, you are running Arch. You can try the packages here:

http://www.unexicon.com/repo/pkgs/arch/os/x86_64/custom/adwm-0.5.6-1-x86_64.pkg.tar.xz http://www.unexicon.com/repo/pkgs/arch/os/x86_64/custom/adwm-git-0.5.6.r1.g2bed8ab-1-x86_64.pkg.tar.xz

(Just download them and use pacman -U to install.) These are the two binaries that I am running on Arch. Neither cause me any problems. I tried launching them directly from a console with

startx /usr/bin/adwm

and still no problem.

[mxmilkiib]

Same error with those packages. I tried cloning and building directly (instead of through AUR adwm-git) just in case, same error again :/

[bbidulock]

Strange. I have 5 up-to-date Arch linux systems here with those packages and no error on any of them. I don't have any more ideas.

[mxmilkiib]

with CFLAGS=-g3 it crashes out after

Breakpoint 1, getpointer (x=0x7fffffffda74, y=0x7fffffffda70) at adwm.c:2436 2436 XQueryPointer(dpy, scr->root, &dummy, &dummy, x, y, &di, &di, &dui); (gdb) print dpy $1 = (Display *) 0x657500

might that help? i'm starting to learn gdb, anything else i can try?

[bbidulock]

Maybe pointer aliasing?

[bbidulock]

Do you happen to be running multiple monitors? The original error appears to be one of the calls to XFixesCreatePointerBarrier in updatemonitors() in src/adwm.c.

[mxmilkiib]

Yes, I've a dual head setup.

[bbidulock]

That's it then. I haven't really tested dual head. Just a bit with dmx. The updatemonitors() is attempting to create a pointer barrier in the corners of each monitor so edge of monitor can be selected in each monitor of the screen. It works ok for single-head, but is obviously issuing the command (XFixesCreatePointerBarrier) with a wrong parameter for one of your monitors.

[bbidulock]

Sorry, updatebarriers().

[bbidulock]

The error code 129 translates to BadBarrier error.

[bbidulock]

Ok, looks to me like I am attempting to define overlapping barriers for the edges of the monitors that are adjacent to each other. Need a little smarter logic in updatebarriers. I will attempt a fix.

[bbidulock]

If you try the latest adwm-git from AUR I think that you will find this error no longer occurs. There may be other issues with multi-head configurations, but this one is fixed, I believe.

[mxmilkiib]

That did the trick, thank you!