Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 32459 - Several Video players completely crash XFree86/NVIDIA when Xserver is not restarted between users
Summary: Several Video players completely crash XFree86/NVIDIA when Xserver is not res...
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: x86 Linux
: High critical (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-01 05:54 UTC by Jez Bromley
Modified: 2004-04-07 17:34 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jez Bromley 2003-11-01 05:54:27 UTC
Playing videos will often completely crash the Xserver (when using the NVIDIA 
drivers), forcing a user to log back in.  Upon logging back in things appear to 
work fine.  But when a new user later logs in the problem occurs again. 
 
I have personally experienced this problem with mplayer, but the following 
thread in the forums suggests the problem is widespread and occurs with several 
video players (totem, aviplay, possibly xine): 
 
http://forums.gentoo.org/viewtopic.php?t=33954&postdays=0&postorder=asc&start=0 
 
After some investigation on my own setup, I have discovered that this problem 
completely disappears if one adds: 
 
TerminateServer=true 
 
to the [X-*-Core] section of /usr/kde/3.1/share/config/kdm/kdmrc 
 
Which forces the Xserver to be restarted rather than merely reset between 
different logins. 
 
This suggests that the problem has to do with either XFree86 or the NVIDIA 
drivers not cleaning up properly between resets of the server, or alternatively 
that kdm is not resetting the Xserver in the correct fashion.  Unfortunately my 
programming/debugging skills are not up to the task of seperating which of 
these issues is true... 
 
If other people can confirm this bug, then as an interim measure it might be an 
idea to adjust the default ebuild so that kdm is installed with the 
TerminateServer=true option enabled.  Unfortunately this option will be 
clobbered if a user ever tries to change the kdm configuration from the KDE 
Control Centre settings. 

Reproducible: Always
Steps to Reproduce:
1. Have kdm set up WITHOUT TerminateServer=true, and XFree86 using the NVIDIA 
drivers 
2. Log in via kdm as User A 
3. Play a video file with mplayer (I've been using QuickTime files) 
4. Log out 
5. Log in via kdm as User B 
6. Play a video file with mplayer 
7. Log out 
8. Log in via kdm as User A 
9. Play a video file with mplayer.  By this point, if not sooner the problem 
will usually have occurred.  For myself I can always consistently produce it by 
this 'cyclic' procedure.  Although some other users in the forums have claimed 
it is more sporadic. 
Actual Results:  
Mplayer will crash the Xserver before successfully playing any video, forcing 
kdm to restart (often on VT8 instead of VT7).  If the SAME user then logs 
directly back in again, the problem will disappear for the duration of their 
login session.  However when another user logs in the problem will start again.  
In my experience once you have managed to trigger the problem by the above 
steps, it will always happen every time a new user logs in.  Examining the 
output from mplayer in these cases shows that it was killed by signal 1, 
suggesting the Xserver crashes while it is still running. 

Expected Results:  
X should not crash. 

I myself am using XFree86 4.2.1, the 3123 NVIDIA drivers, a 2.4.20-ck6 kernel, 
mplayer 0.92 and kdm from KDE 3.1.4.  However the forum posts show the problem 
appears to occur also for the 4.3 series of Xservers and 4xxx series of NVIDIA 
drivers and for various kernels and video players. 
 
Results of emerge --info on my system are as follows: 
 
Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4, 2.4.20-ck6) 
================================================================= 
System uname: 2.4.20-ck6 i686 AMD Duron(tm) processor 
Gentoo Base System version 1.4.2.9 
ACCEPT_KEYWORDS="x86" 
AUTOCLEAN="yes" 
CFLAGS="-march=athlon-tbird -O2 -pipe -momit-leaf-frame-pointer -mmmx -m3dnow" 
CHOST="i686-pc-linux-gnu" 
COMPILER="gcc3" 
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config 
/usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config 
/usr/share/config" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" 
CXXFLAGS="-march=athlon-tbird -O2 -pipe -momit-leaf-frame-pointer -mmmx 
-m3dnow" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="sandbox ccache autoaddcvs" 
GENTOO_MIRRORS="ftp://ftp.mirror.ac.uk/sites/www.ibiblio.org/gentoo 
http://gentoo.oregonstate.edu/ 
http://www.ibiblio.org/pub/Linux/distributions/gentoo" 
MAKEOPTS="-j2" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="/site/portage" 
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" 
USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg gnome libg++ mad 
mikmod mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib 
alsa gdbm berkdb slang readline arts tetex ggi tcltk java guile X sdl tcpd pam 
libwww ssl perl python esd imlib oggvorbis qt kde motif opengl aalib doc dvd 
mbox usb plotutils 3dnow gtk -svga -gpm"
Comment 1 Luca Barbato gentoo-dev 2003-11-01 13:57:30 UTC
is mplayer using xv or other video output?
Comment 2 Jez Bromley 2003-11-02 02:37:29 UTC
OK, I just commented out my "TerminateServer=true" settings and tested with
mplayer using xv, x11, gl and sdl video outputs.  The bug occured for sdl
and xv but not for x11 or gl.  I'm guessing sdl detects and uses Xv, so the
problem is probably Xv related as you suggest...
Comment 3 Andrew Bevitt 2004-04-07 17:34:44 UTC
Does this happen if you are using console logins, eg no xdm/gdm/kdm.

I did the same tests as you with Mplayer and sdl,xv,x11, and gl. 
sdl -> X11, Xv -> X11, and GL and X11 were themselves. Can you save and post the offending mplayer outputs for me aswell please.