This bug has been observed on the X11 server on Mac OS X, both the Apple and the XQuartz versions, has been reported at XQuartz.macosforge.org, but redirected to freedesktop.org (see http://xquartz.macosforge.org/trac/ticket/553). I am guessing as to the correct product and component.
Symptoms: Start an ssh session from a Mac client to a Linux host, using "ssh -X" and the following entry in the client's /etc/ssh_config:
The client's X server starts up and then immediately crashes without any message. With this setting:
there is no problem.
The difference between the two cases is that 596 hours is < 2^31 milliseconds and 597 hours is > 2^31 milliseconds. Some overflow condition is occurring and the server crashes. Instead, it should either report an invalid value, or clamp the value at 2^31 - 1 or whatever is the maximum allowed.
Thread 4 Crashed:
0 libsystem_kernel.dylib 0x00007fff880b1ce2 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff828ff7d2 pthread_kill + 95
2 libsystem_c.dylib 0x00007fff828f0a7a abort + 143
3 libsystem_c.dylib 0x00007fff829235de __assert_rtn + 146
4 X11.bin 0x000000010005270b
SecurityAuthorizationExpired + 107
5 X11.bin 0x00000001000ffea1 TimerSet + 186
6 X11.bin 0x00000001000525db
SecurityStartAuthorizationTimer + 68
7 X11.bin 0x0000000100052493
ProcSecurityGenerateAuthorization + 564
8 X11.bin 0x00000001000bc5d6 Dispatch + 257
9 X11.bin 0x000000010002717e dix_main + 185
10 X11.bin 0x0000000100011b73 server_thread + 38
11 libsystem_c.dylib 0x00007fff828fd8bf _pthread_start + 335
12 libsystem_c.dylib 0x00007fff82900b75 thread_start + 13
Yes, it is very specific to the Mac OS X. And thus, is it strange that it could be linked to a freedesktop bug but I can confirm that it is very annoying problem. We have to close the ssh terminal and restart a new one because you can't open, after the timeout delay, any X window like emacs or whatever software.
Is this a duplicate of bug #27134 ?
I am unable to access bug 27134's description due to permission issues.
FYI: I can't see the linked bug either, but I reproduced this on Debian GNU/Linux (amd64), so its not specific to Mac OS X. There wasn't anything useful in the X log.
Sorry, I lost the version number of the server that was running at the time.
jk. are you saying i have to wait 597 hours to replicate the issue ?
I managed to inadvertently & instantly crash the X server by using xauth with a "large" timeout.
I used a binary search to find the exact value that causes the crash, which is shown below.
To still have a usable environment for debugging, I used xvfb-run to create a new display before fiddling (whenever the fatal error occurs, the server doesn't respond to messages to DISPLAY, and I had to create a new display by passing a new value to xvfb-run).
# Create a new display, :86 and log errors to /tmp/errors.
$ xvfb-run -e /tmp/errors -n 86 bash
# This is a new (Bash) shell. Create an authorization file and then use xauth.
# All is fine with 2147483...
$ foo=/tmp/xauthfile$DISPLAY; truncate -s 0 $foo ; xauth -f $foo generate $DISPLAY . untrusted timeout 2147483
# When I use 2147484, the server crashes.
$ foo=/tmp/xauthfile$DISPLAY; truncate -s 0 $foo ; xauth -f $foo generate $DISPLAY . untrusted timeout 2147484
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":86"
after 11 requests (11 known processed) with 0 events remaining.
# Well, since $DISPLAY (= :86) is unusable, exit the subshell. For some reason, Xvfb crashes upon exit.
/usr/bin/xvfb-run: line 170: 4393 Aborted (core dumped) XAUTHORITY=$AUTHFILE Xvfb ":$SERVERNUM" $XVFBARGS $LISTENTCP >> "$ERRORFILE" 2>&1
/usr/bin/xvfb-run: line 175: kill: (4393) - No such process
# This is the cause of the crash, some assertion failure...
$ cat /tmp/errors
xauth: file /tmp/xvfb-run.UyS843/Xauthority does not exist
Xvfb: security.c:300: SecurityAuthorizationExpired: Assertion `pAuth->timer == timer' failed.
Xorg-server version: 1.18.1 (built using https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xorg-server&id=ebc54a20f035357845ce082c6023c39fa792fc9b)
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/421.