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

[Tim Connors]

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