Bug#637611: mplayer: redirected stdin from /dev/null causes 100% busy loop

August 12th, 2011 - 11:00 pm ET by Tim Connors | Report spam
Package: mplayer
Version: 3:1.0~rc4+svn20110505-0.2
Severity: normal

It seems that relatively recently there has been a regression where
the keyboard reading from /dev/stdin doesn't do appropriate error
checking. If /dev/stdin is redirected from /dev/null (eg, when
mplayer is run from a cronjob), strace shows:

select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
read(0, "", 256) = 0
select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
read(0, "", 256) = 0
select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
read(0, "", 256) = 0
select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9996})
read(0, "", 256) = 0

The parent process is stuck read()ing with a return code that should
imply EOF. mplayer appears not to check for EOF, so just reads again
immediately. Fortunately, the worker process is still doing its job,
but my poor dualcore CPU in my laptop is getting a bit warm.

(If I simply redirect /dev/stdin to a named pipe with no writer
connected to it, then mplayer doesn't even start up because it's
blocking on read. So that's not a suitable workaround)

Debian Release: 6.0.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'oldstable'), (500, 'stable'), (5, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mplayer depends on:
ii liba52 0.7.4-14 library for decoding ATSC A/52 str
ii libaa1 1.4p5-38 ascii art library
ii libaso 1.0.23-2.1 shared library for ALSA applicatio
ii libatk 1.30.0-1 The ATK accessibility toolkit
ii libaud 1.9.2-4 Network Audio System - shared libr
ii libbs2 3.1.0-0.2 Bauer stereophonic-to-binaural DSP
ii libbz2 1.0.5-6 high-quality block-sorting file co
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libcac 0.99.beta17-1 colour ASCII art library
ii libcai 1.8.10-6 The Cairo 2D vector graphics libra
ii libcdp 3.10.2+debian-9 audio extraction tool for sampling
ii libdca 0.0.5-3 decoding library for DTS Coherent
ii libdir 1.0.2-3 open and royalty free high quality
ii libdir 1.0.2-3 open and royalty free high quality
ii libdir 1.2.10.0-4 direct frame buffer graphics - sha
ii libdv4 1.0.0-2.1 software library for DV format dig
ii libenc 1.13-3 Extremely Naive Charset Analyser -
ii libfaa 1.28-0.3 an AAC audio encoder - library fil
ii libfaa 2.7-6 freeware Advanced Audio Decoder -
ii libfon 2.8.0-2.1 generic font configuration library
ii libfre 2.4.2-2.1 FreeType 2 font engine, shared lib
ii libfri 0.19.2-1 Free Implementation of the Unicode
ii libgcc 1:4.4.5-8 GCC support library
ii libgdk 2.23.5-1 GDK Pixbuf library
ii libggi 1:2.2.2-5 General Graphics Interface runtime
ii libggi 0.3.2-2 GGI Window Manager Hints extension
ii libgif 4.1.6-9 library for GIF images (library)
ii libgl1 7.7.1-4 A free implementation of the OpenG
ii libgli 2.28.6-1 The GLib library of C routines
ii libgtk 2.24.5-2 GTK+ graphical user interface libr
ii libjac 1:0.118+svn3796-7 JACK Audio Connection Kit (librari
ii libjpe 8c-2 Independent JPEG Group's JPEG runt
ii liblir 0.8.3-5 infra-red remote control support -
ii liblzo 2.03-2 data compression library
ii libmad 0.15.1b-5 MPEG audio decoder library
ii libmng 1.0.10-1+b1 Multiple-image Network Graphics li
ii libmp3 1:3.98.4-0.2 LAME Ain't an MP3 Encoder (shared
ii libncu 5.7+20100313-5 shared libraries for terminal hand
ii libogg 1.2.0~dfsg-1 Ogg bitstream library
ii libope 0.1.2-1 Adaptive Multi Rate speech codec -
ii libope 0.1.2-1 Adaptive Multi-Rate - Wideband spe
ii libope 1.3+dfsg-4 JPEG 2000 image compression/decomp
ii libpan 1.28.3-1+squeeze2 Layout and rendering of internatio
ii libpng 1.2.44-1+squeeze1 PNG library - runtime
ii libpul 0.9.21-3+squeeze1 PulseAudio client libraries
ii librtm 2.3-2 toolkit for RTMP streams (shared l
ii libsch 1.0.9-2 library for encoding/decoding of D
ii libsdl 1.2.14-6.1 Simple DirectMedia Layer
ii libsmb 2:3.5.6~dfsg-3squeeze5 shared library for communication w
ii libspe 1.2~rc1-1 The Speex codec runtime library
ii libstd 4.6.0-2 The GNU Standard C++ Library v3
ii libsvg 1:1.4.3-29 console SVGA display libraries
ii libthe 1.1.1+dfsg.1-3 The Theora Video Compression Codec
ii libvdp 0.4.1-2 Video Decode and Presentation API
ii libvor 1.3.1-1 The Vorbis General Audio Compressi
ii libvor 1.3.1-1 The Vorbis General Audio Compressi
ii libvpx 0.9.1-2 VP8 video codec (shared library)
ii libx11 2:1.3.3-4 X11 client-side library
ii libx26 2:0.116.2037+gitf8ebd4a-3~bpo60+1 x264 video coding library
ii libxex 2:1.1.2-1 X11 miscellaneous extension librar
ii libxin 2:1.1-3 X11 Xinerama extension library
ii libxss 1:1.2.0-2 X11 Screen Saver extension library
ii libxt6 1:1.0.7-1 X11 toolkit intrinsics library
ii libxv1 2:1.0.5-1 X11 Video extension library
ii libxvi 2:1.2.2-0.1 High quality ISO MPEG4 codec libra
ii libxvm 2:1.0.5-1 X11 Video extension library
ii libxxf 2:1.1.1-2 X11 Direct Graphics Access extensi
ii libxxf 1:1.1.0-2 X11 XFree86 video mode extension l
ii mplaye 1.6-2 blue skin for mplayer
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime

mplayer recommends no packages.

Versions of packages mplayer suggests:
pn jackd <none> (no description available)
ii libdvdcss2 [libdvdcss] 1.2.10-0.3 Simple foundation for reading DVDs
pn mplayer-doc <none> (no description available)
ii nvidia-vdpau-driver 275.09.07-5 NVIDIA vdpau driver
pn pulseaudio <none> (no description available)




To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 2 repliesReplies Make a reply

Similar topics

Replies

#1 Reimar Döffinger
August 13th, 2011 - 06:10 am ET | Report spam
On Sat, Aug 13, 2011 at 12:50:19PM +1000, Tim Connors wrote:
It seems that relatively recently there has been a regression where
the keyboard reading from /dev/stdin doesn't do appropriate error
checking. If /dev/stdin is redirected from /dev/null (eg, when
mplayer is run from a cronjob), strace shows:

select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
read(0, "", 256) = 0
select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
read(0, "", 256) = 0
select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
read(0, "", 256) = 0
select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9996})
read(0, "", 256) = 0

The parent process is stuck read()ing with a return code that should
imply EOF. mplayer appears not to check for EOF, so just reads again
immediately. Fortunately, the worker process is still doing its job,
but my poor dualcore CPU in my laptop is getting a bit warm.

(If I simply redirect /dev/stdin to a named pipe with no writer
connected to it, then mplayer doesn't even start up because it's
blocking on read. So that's not a suitable workaround)



Behaviour is to make keyboard control of MPlayer more reliable mostly I
expect.
I think the MPlayer documentation says you must use -noconsolecontrols
when using MPlayer without a terminal (in particular from cron jobs).



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Replies Reply to this message
#2 Tim Connors
August 13th, 2011 - 07:00 am ET | Report spam
On Sat, 13 Aug 2011, Reimar Döffinger wrote:

On Sat, Aug 13, 2011 at 12:50:19PM +1000, Tim Connors wrote:
> It seems that relatively recently there has been a regression where
> the keyboard reading from /dev/stdin doesn't do appropriate error
> checking. If /dev/stdin is redirected from /dev/null (eg, when
> mplayer is run from a cronjob), strace shows:
>
> select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
> read(0, "", 256) = 0
> select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
> read(0, "", 256) = 0
> select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9997})
> read(0, "", 256) = 0
> select(1, [0], NULL, NULL, {0, 10000}) = 1 (in [0], left {0, 9996})
> read(0, "", 256) = 0
>
> The parent process is stuck read()ing with a return code that should
> imply EOF. mplayer appears not to check for EOF, so just reads again
> immediately. Fortunately, the worker process is still doing its job,
> but my poor dualcore CPU in my laptop is getting a bit warm.
>
> (If I simply redirect /dev/stdin to a named pipe with no writer
> connected to it, then mplayer doesn't even start up because it's
> blocking on read. So that's not a suitable workaround)

Behaviour is to make keyboard control of MPlayer more reliable mostly I
expect.
I think the MPlayer documentation says you must use -noconsolecontrols
when using MPlayer without a terminal (in particular from cron jobs).



The description in the manpage doens't cover this case (stdin being
/dev/null rather than a command file or the file being played).

And it makes matters worse. CPU usage is still 100%, but I can't see why.
strace -f doesn't show it busy looping on file descriptor 0 - it's just
reading the input file and sending stuff to X11.

Yet, if I remove the stdin redirection from /dev/null, then cpu usage
drops back to < 10% as it should.

The one workaround I have found is:

cat /tmp/devblocker |
mplayer $args -dumpaudio -dumpfile <out.mp3> <network_stream>

(where /tmp/devblocker is a named pipe with no writer attached to it).
(yes, this is a candidate for the 'useless use of cat' awards, but
removing the cat doesn't let mplayer start, presumably because mplayer is
trying to read its first keyboard command, but does it using a blocking
read. No idea why it woks with the cat process attached! Figure that
out:
mplayer $args -dumpaudio -dumpfile <out.mp3> <network_stream> < /tmp/devblocker
)

Tim Connors



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
email Follow the discussion Replies Reply to this message
Help Create a new topicReplies Make a reply
Search Make your own search