Bug 47053 - X server crashes with large timer
Summary: X server crashes with large timer
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: All All
: high major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard: 2012BRB_Reviewed
Keywords:
Depends on:
Blocks: xserver-1.14
  Show dependency treegraph
 
Reported: 2012-03-07 06:53 UTC by Mike
Modified: 2018-12-13 22:26 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2012-03-07 06:53:24 UTC
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:

ForwardX11Timeout 597h

The client's X server starts up and then immediately crashes without any message.  With this setting:


ForwardX11Timeout 596h

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.
Comment 1 Jeremy Huddleston Sequoia 2012-06-12 04:10:22 UTC
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
Comment 2 nicolas.brouard 2012-09-26 09:39:17 UTC
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.
Comment 3 Alan Coopersmith 2013-02-10 17:18:49 UTC
Is this a duplicate of bug #27134 ?
Comment 4 Mike 2013-02-10 20:24:28 UTC
I am unable to access bug 27134's description due to permission issues.
Comment 5 Anthony DeRobertis 2014-01-02 13:53:42 UTC
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.
Comment 6 debguy 2014-11-28 15:51:34 UTC
jk.  are you saying i have to wait 597 hours to replicate the issue ?
Comment 7 Rob 2016-02-25 16:02:18 UTC
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. 
$ 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.

OS: ArchLinux.
Xorg-server version: 1.18.1 (built using https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xorg-server&id=ebc54a20f035357845ce082c6023c39fa792fc9b)
Comment 8 GitLab Migration User 2018-12-13 22:26:26 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.