Uninitialised storage? (no advance in playlist is a *real* bug)

Having installed xmms-1.2.7 under FreeBSD-4.8, I had a problem whereby it
would never advance from the current track to the next track - and before
you say it, no this is nothing to do with the Ctrl-N feature!

In fact this seems to have been reported by several times before [*], but
presumably only occurs for a few people otherwise it would have been fixed
by now.

Anyway, armed with fprintf(stderr), I tried to track down the problem.
Here's what I found:

(1) in xmms/main.c, playlist_eof_reached() is never called. This is because
    input_get_time() is never returning -1; instead it just keeps returning
    the time offset of the end of the song.

I have printf evidence of this:

(302432).(302445).(302458).(302471).(302484).(302497).(302511).(302524).
(302537).(302550).(302563).(302576).(302589).(302602).(302602).(302602).
(302602).(302602).(302602).(302602).(302602).(302602).(302602).(302602).
(302602).(302602).(302602).(302602).(302602).(302602).(302602).(302602).
(302602).(302602).(302602).(302602).(302602).(302602).(302602).(302602).
(302602).(302602).(302602).(302602)...etc

So as far as the main loop is concerned, the track is still playing.

(2) This in turn derives from get_time() in Input/mpg123/mpg123.c
It's supposed to return -1 at the end of the track:

        if (!mpg123_info->going || (mpg123_info->eof && !mpg123_ip.output->buffer_playing()))
                return -1;

Unfortunately, at this point, I made a mistake. I added fprintf's to mpg123.c
and re-ran xmms in its current location, but it was still picking up the
shared libraries as were installed from the FreeBSD package. So I removed
the FreeBSD package and make-installed the one I was working on. Hey presto,
not only did my printf's work, but so did advancing to the next track :-(

I did a make uninstall, reinstalled the FreeBSD package, and it's still
working. Even a shutdown and power-off has not put it back how it was.

So I can only imagine that there is something which depends on a bit of
uninitialized memory, which means that either mpg123_info->eof is not being
set to 1 at the end of the track, or that mpg123_ip.output->buffer_playing()
is permanently returning 1 - perhaps something in oss_playing().

There is a related problem I'd also noticed, which has also gone away. If
while playing a track I pressed C (pause) followed by V (stop) then X
(play), the track would rewind to 00:00 but would remain paused. I would
have to press C twice more to get the track to start. Also, on the second
'C' I would hear a very short splat of audio before the track started.

This no longer happens, and I feel pretty sure that the two problems are
linked some way - some variable to do with "track is playing" was getting
into a strange state. Is it possible that when the .so is being loaded, it
is not initialising its static storage area?

The other strangeness was when I first installed xmms, the default output
device selected was the DiskWriter, and so I was getting no audio and the
track time was decrementing at about 3 times real time. I found this one in
the FAQ, but it also hints at uninitialised storage, since I'm sure xmms was
never intended to choose that as its default :-)

If I stop xmms, rm -rf ~/.xmms and restart it, it is now properly choosing
OSS as the default every time. Argh!

Anyway, next time someone reports this problem, you can know that it's real.
Maybe adding explicit initialisation code for all state variables wouldn't
be a bad idea.

Regards,

Brian.

[*] references:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=1a6d3cff8f31e399&seekm=pan.2002.11.11.17.50.51.70491.20906%40cooke-one.madhouse&rnum=4
http://lists.xmms.org/pipermail/xmms-devel/2003-February/002500.html

In both cases the person with the problem made sure that 'no playlist
advance' was not selected - as did I.