Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 332715 - x11-base/xorg-server crashes on VT switch
Summary: x11-base/xorg-server crashes on VT switch
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo X packagers
URL: N/A
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-14 11:08 UTC by Robert Bradbury
Modified: 2015-02-22 21:47 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (EmrgInfo.lst,4.26 KB, text/plain)
2010-08-14 11:09 UTC, Robert Bradbury
Details
Edited stack trace of core dump (core.X-2-switch.eddbg,4.87 KB, text/plain)
2010-08-14 11:13 UTC, Robert Bradbury
Details
xorg.conf (xorg.conf,24.83 KB, text/plain)
2010-08-17 12:14 UTC, Robert Bradbury
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Bradbury 2010-08-14 11:08:25 UTC
After running on one virtual terminal for a while and executing a VT switch to another terminal, switching back to the original terminal fails (session has been closed/lost).

Reproducible: Sometimes

Steps to Reproduce:
1. Start multiple X servers.
2. Login as different users on multiple X terminals
3. Switch back and forth between various VTs/sessions (ctrl-Alt-Fn).

Actual Results:  
Either switch away from or back to the session causes the X server to crash.
Server carsh produces a core dump.  Trace reveals that the crash was due to a SEGV due to a stack overflow.

It does not happen all of the time.  It seems to most frequently happen after there has been some lag time (hours to days) between the attempts to switch terminals/sessions (perhaps timing issues due to unused pages being paged out???).

Expected Results:  
X server should *reliably* switch between VTs/sessions.


This has been seen across multiple recent (2010) releases of X and many of the drivers involved.  It may be related to the addition of the KMS features.

Hardware/drivers are for "intel" but may also have seen it on "radeon".

The key call stack trace information is:
#174601 0x08167682 in xf86XVEnterVT (index=0, flags=0) at xf86xv.c:1232
#174602 0xb730db5c in glxDRIEnterVT (index=0, flags=0) at glxdri2.c:592
#174603 0x080ad141 in xf86VTSwitch (blockData=0x0, err=-1, pReadmask=0x81e3c80) at xf86Events.c:533
#174604 xf86Wakeup (blockData=0x0, err=-1, pReadmask=0x81e3c80) at xf86Events.c:284
#174605 0x08075220 in WakeupHandler (result=-1, pReadmask=0x81e3c80) at dixutils.c:403
#174606 0x0809d6d3 in WaitForSomething (pClientsReady=0x82f0cf0) at WaitFor.c:232


As a side note, the X server should make an effort to restrict the size of its stack to some "reasonable" value.  The large core dumps (15-25 megabytes) can frequently cause the root file system to run out of space.  Arguably, there should be an X-call which would have the X-server to "chdir" to the home directory of the logged in user so the core dumps end up there.
Comment 1 Robert Bradbury 2010-08-14 11:09:30 UTC
Created attachment 242929 [details]
emerge --info
Comment 2 Robert Bradbury 2010-08-14 11:13:04 UTC
Created attachment 242931 [details]
Edited stack trace of core dump

Edited stack trace from core dump.  Full stack trace is over 15MB and doesn't seem to provide any additional useful information due to recursion loop.
Comment 3 Wormo (RETIRED) gentoo-dev 2010-08-17 02:03:53 UTC
(In reply to comment #0)

> As a side note, the X server should make an effort to restrict the size of its
> stack to some "reasonable" value.  The large core dumps (15-25 megabytes) can
> frequently cause the root file system to run out of space. 

Filling up the root file system is certainly an annoying habit...
I'm not sure what you're using to start X, but this seems like a job for 'ulimit -c <something reasonable>' in one of your X startup files. 

Comment 4 Wormo (RETIRED) gentoo-dev 2010-08-17 02:19:47 UTC
Here's a guess from a quick look at your backtrace and xf86RandR12.c -- the problem might occur when you've got something using 3d and/or video acceleration, since I see xf86XVEnterVT and glxDRIEnterVT handlers in the callstack. Can you trigger it more often if you purposefully switch back and forth while playing movies and running glx apps?
Comment 5 Robert Bradbury 2010-08-17 12:01:57 UTC
The suggestion of using ulimit to limit stack size is reasonable (ulimit -s [1]) but as X runs as root I'm not sure that it would be respected unless it were set as a hard limit at the system level (begs the question of when X will be able to run as a non-SU process -- which is what I thought one of the goals of KMS setting was).  I am open to "patches" which would adjust the stack ulimit for X (presumably in /etc/init.d/xdm).

With respect to glx being a factor.  I had not noticed that.  I don't run anything "fancy" like 3D.  Its mostly xterm's and browsers (epiphany, firefox, chrome, seamonkey, opera) which may be active in one or more of the VTs.  Generally speaking I've got the browsers on highly restricted behavior (i.e. NoScript on almost all sites).  They can play videos when I request but I'm not normally playing YouTube in background and switching VTs.

I've tried to reproduce it by quickly switching back and forth between VTs and have not been able to do so.  VT switches (I typically run/work as 2-4 users) generally work as they are supposed to when actively testing.  It is when there is some latency (hours) between the switches that the problem seems to reveal itself.  As stated, the problem is "new" -- not having existed 1, 2, 3 years ago (developing in the last 6-12 months) but it has persisted through several recent X and associated driver library iterations.  I believe though am not sure that I have seen it with both the Intel as well as the radeon X drivers (I wanted to run multi-terminal across the two drivers but apparently current X/xrandr implementations don't support that -- though old xinerama interfaces may).  The problem (stack overflow) definitely does occur with the current X and intel driver.

1. Ulimit -c isn't the right solution because I would really like to have the core files.  I would just like them to be "meaningful".   I've got a fair number of Firefox/Epiphany core dumps which are useless because they either hit the default "-c" limit or ran out of space on the partition.  I've taken to running them with an increased ulimit -c (up to about 3GB which is the address limit on an x86) on a partition where there is that much space available.  The trick is to limit the size to which the stack can grow in X (or other browsers).  The greatest "typical" call stack size I've seen is around 200 function calls (in a browser) and I doubt that comes anywhere close to 8 MB.
Comment 6 Robert Bradbury 2010-08-17 12:14:47 UTC
Created attachment 243325 [details]
xorg.conf

xorg.conf from session which had problems.  Shows some left-overs of attempts to run dual/tri- monitor on two drivers (intel + radeon).  The current bug report was using only a single monitor on the Intel hardware.
Comment 7 Matt Turner gentoo-dev 2015-02-22 21:47:53 UTC
Hopefully fixed long ago.