Short story: I start a movie with mplayer, close the player window with the X in the upper right corner, the window goes away but there is still an mplayer process around. Long story: 1) Make sure no mplayer is running: obelix@home ~ $ pgrep -l mplayer obelix@home ~ $ 2) Start a movie in one console obelix@home ~ $ mplayer somefilm MPlayer 1.0pre7-3.4.4 (C) 2000-2005 MPlayer Team CPU: Intel Pentium 4/Xeon/Celeron Northwood (Family: 8, Stepping: 4) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 ... <The movie is playing in a window> 3) Check for mplayers again. obelix@home ~ $ pgrep -l mplayer 20755 mplayer 20756 mplayer obelix@home ~ $ Two of them. Is this normal ? Let's trace them. 4) Trace the first in one console obelix@home ~ $ strace -p 20755 5) Trace the other in an other console obelix@home ~ $ strace -p 20756 <tons of text scrolling fast> 6) Close the movie by clicking on the X in the upper right corner. <click> 7) Observer that the first trace has terminated with something like: gettimeofday({1122046302, 397072}, {4294967116, 0}) = 0 gettimeofday({1122046302, 397130}, {4294967116, 0}) = 0 write(5, "\214\23\r\0\16\1\0\0\1\0 \3\6\0 \3\10\0 \3YV12\0\0\0\0"..., 52) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- Process 20755 detached obelix@home ~ $ 8) Observe that the second has gone into an infinte loop repeatedly printing: nanosleep({0, 50000000}, NULL) = 0 9) Check for mplayers again obelix@home ~ $ pgrep -l mplayer 20756 mplayer obelix@home ~ $ ps -eo pid,user,args,rss | grep mplayer 20756 obelix mplayer somefilm 16488 obelix@home ~ $ Bad. One is still around, holding 16MB of memory, should not be. Reproducible: Always Steps to Reproduce: Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -mtune=pentium4 -fomit-frame-pointer -momit-leaf-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -mtune=pentium4 -fomit-frame-pointer -momit-leaf-frame-pointer -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.ITDNet.net/gentoo" LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl alsa apache2 avi bash-completion berkdb bitmap-fonts bonobo cdr crypt cups curl directfb doc dvd dvdr eds emboss encode flac foomaticdb gd gdbm gif gnome gpm gstreamer gtk gtk2 guile hal imagemagick imlib ipv6 ithreads java jpeg junit kde kdeenablefinal ldap libg++ libwww mad mikmod mmap mmx motif mozilla mp3 mpeg mysql ncurses nls nptl nvidia ogg oggvorbis opengl pam pdflib perl pic plotutils png postgres pthreads python qt quicktime readline sdl session sharedmem spell sse sse2 ssl svga symlink tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts unicode usb vorbis win32codecs xml xml2 xmms xv zlib linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
(In reply to comment #0) > 3) Check for mplayers again. > > obelix@home ~ $ pgrep -l mplayer > 20755 mplayer > 20756 mplayer > obelix@home ~ $ > > Two of them. Is this normal ? Let's trace them. Yes, it is normal whe you have a cache, -nocache works > 6) Close the movie by clicking on the X in the upper right corner. This is method is only supported when using -vo sdl or gmplayer. Unfortunately some Window Managers think they are especially bright and do something (I was told they just deleted the window) that in the end leads to MPlayer crashing and so the other instance stays around (IMHO that's just like people switching off their PC by pulling the plug - just so you know, my fluxbox version here simply does not show the X) > --- SIGPIPE (Broken pipe) @ 0 (0) --- Hmmm... I guess we could catch SIGPIPE just like SIGKILL and the others, that might make the situation a bit better... > 8) Observe that the second has gone into an infinte loop repeatedly printing: No surprise, it still waits for the other to read from it..
The wm in question is metacity 2.10.2. I am a Gnome user. > Hmmm... I guess we could catch SIGPIPE just like SIGKILL and the others, that > might make the situation a bit better... You mean catch the SIGPIPE in one process and kill both ? I guess this will solve the issue. > Unfortunately some Window Managers think they are especially bright and do > something (I was told they just deleted the window) that in the end leads to > MPlayer crashing and so the other instance stays around I think you should catch all catchable signals that lead to termination ( I guess this means almost all of them, except SIGKILL and few others ) and make sure both processes are terminated. Even if mplayer really crashes ( due to a bug, not due to clicking the X ) the other instance should not stay around.
> I think you should catch all catchable signals that lead to termination ( I > guess this means almost all of them, except SIGKILL and few others ) and make It catches most, but getting all and making sure that it still compiles is not that easy (MinGW is especially annoying here). Anyway, it now (CVS) catches also SIGPIPE and SIGHUP, so this particular problem should be fixed (though it still isn't the "gentle" way to quit MPlayer). > sure both processes are terminated. Even if mplayer really crashes ( due to a > bug, not due to clicking the X ) the other instance should not stay around. The other cases were already taken care of (since a long time already).
> Anyway, it now (CVS) catches also SIGPIPE and SIGHUP, so this particular > problem should be fixed (though it still isn't the "gentle" way to quit > MPlayer). Great ! Thanks a lot. Unless you are going to make a new (pre)release soon, can you please post the patch against mplayer-1.0_pre7 ?
Created attachment 64457 [details, diff] Catch SIGPIPE This will stop some effects, but e.g. dpms and the screensaver still won't get reenabled when you close MPlayer by clicking the close button.
> but e.g. dpms and the screensaver still won't get reenabled Why not ? What is the problem with reenabling them ?
> > but e.g. dpms and the screensaver still won't get reenabled > Why not ? What is the problem with reenabling them ? As I understand it, when MPlayer gets the SIGPIPE it has lost the connection to the X server, so it simply can't tell X to enable these again...
Hmm... this is a serious problem. A few things come to mind: 1) When the player window is focused I can press q to quit, can't you attach a handler to the close event that quits gracefuly ? 2) You can call "xscreensaver-command -restart" on exit. This will restart the xscreensaver process and restart the idle-timer and clear any disabled-flags off dpms and the screensaver. 3) Can't you reastablish the connection to X to reenable dpms and screensaver ?
(In reply to comment #8) > Hmm... this is a serious problem. A few things come to mind: > > 1) When the player window is focused I can press q to quit, can't you attach a > handler to the close event that quits gracefuly ? gmplayer does it, so yes it is possible. But I don't see a chance this will be done by any of the MPlayer developers (thus the bugzilla entry for MPlayer is WONTFIX, but we sure accept patches...) > 2) You can call "xscreensaver-command -restart" on exit. This will restart the > xscreensaver process and restart the idle-timer and clear any disabled-flags off > dpms and the screensaver. > 3) Can't you reastablish the connection to X to reenable dpms and screensaver ? Not acceptable in an exception/trap/fault handler IMHO.
> > 2) You can call "xscreensaver-command -restart" on exit. > Not acceptable in an exception/trap/fault handler IMHO. Can't "xscreensaver-command -restart" be called before exit without putting in an exception/trap/fault handler ? We need just to make sure it is called before exit. For example, I am using the following script wrapper to do it: /usr/bin/mplayer "$@" xscreensaver-command -restart I have called this mplayer and put it before the real mplayer in my $PATH, as a workaround.
Cleaning out old bugs, please reopen if still present in newer versions. Thanks Ivan
