Re: startx xauth fails after upgrade to Bullseye 11.3
Esteemed Debian experts and maintainers -
On Sun, Mar 27, 2022 at 11:26:37PM -0700, Larry Doolittle wrote:
> On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote:
> > I just upgraded my first machine from 11.2 to 11.3.
> > xauth fails in the context of startx.
> Workaround: create an empty directory, cd to that, and then startx.
> Something about running startx (and therefore xauth) in my home
> directory has it very confused.
The key command is
xauth list $(hostname -f):0
When run in my home directory, it yields a Segmentation fault,
and leaves behind two zero-length lock files
.Xauthority-l .Xauthority-c
that are hard-linked together. I have to remove those files before
continuing. When run in an empty subdirectory, that xauth command
(correctly) prints one line with an MIT-MAGIC-COOKIE-1, and
does not segfault.
In the context of /usr/bin/startx (xinit-1.4.0-1), this fault shows up
in line 199-200
authcookie=`xauth list "$displayname" \
| sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null;
and the lock files left behind prevent the following xauth calls from
functioning.
I can run xauth (xauth-1:1.1-1) under gdb, but until and unless I recompile
it with debugging symbols, the result is not so helpful:
Program received signal SIGSEGV, Segmentation fault.
__strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
301 ../sysdeps/x86_64/multiarch/strcpy-avx2.S: No such file or directory.
(gdb) bt
#0 __strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
#1 0x0000555555558cc3 in ?? ()
#2 0x0000555555559c8c in ?? ()
#3 0x000055555555a53d in ?? ()
#4 0x000055555555aa1e in ?? ()
#5 0x0000555555558634 in ?? ()
#6 0x00007ffff7ca0d0a in __libc_start_main (main=0x555555558480, argc=3,
argv=0x7fffffffe378, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe368)
at ../csu/libc-start.c:308
#7 0x000055555555870a in ?? ()
(gdb)
This behavior started when I upgraded to Bullseye 11.3 from 11.2.
Until I understand the fault and its trigger better, I can't guarantee
that wasn't a coincidence. The xauth segfault is definitely real and
a problem for me.
- Larry
Reply to: