[icecast] Memory leak in ices-2

Michael Smith msmith at labyrinth.net.au
Wed Nov 7 13:45:37 UTC 2001

At 08:09 AM 11/7/01 -0500, you wrote:
>Hi everyone:  I am running a couple of ices2 streams one with a fairly
>small playlist and one with a play list which is currently about 1000
>pieces.  The 1000 piece stream appears to have a bad memory leak.  The
>streamer dies about every 16 to 20 hours with a process out of memory
>error.  Has anyone else seen this problem or have any suggestions?
>The stream with the smaller play list appears to not have any problems
>at all.

I've committed something which might (but I doubt it) be the cause of 
this - it's worth a try, at least, I guess.

Is the playlist being reloaded very frequently? (playlist reloads get
logged at level INFO) - even if it were, that shouldn't leak enough
to be noticable in under a day. If not, then the length of the playlist
should be irrelevent - unless there's a bad entry, or an entry pointing
to a bad file, that it's choking on.

You're not reencoding or anything? The reencoding code (or just
encoding, though that's less likely) is by far the most likely culprit
for major leaks. If you are, can you turn this off for a day or so to
ensure that this is the problem?

I saw something like this a couple of weeks ago locally - I'd left things
running (xmms, icecast2, ices2) overnight, and when I came home the
following day the kernel had killed off all three - I didn't have time
to look into things then. Maybe this was the same problem? I don't know
what setup I was running at the time.

>I am using ices2 and libshout2 out of cvs.  The ogg encoding is
>44100hz stereo encoded at oggenc's default compression.  The stream is
>feeding two streams, one at 128 bits and the other at 64.  I also have
>a hunch the pieces are occasionally getting clipped off before their
>end but I'm not a hundred percent sure because it does not always
>happen.  Fairly rarely actually.

I haven't noticed this, but I haven't done extensive testing lately
(an automated test-suite is really hard to construct for this sort of 
thing, since a lot of the things I'd want to test for are VERY highly
timing dependent. Still, it'd be nice to have...)

If you can confirm that it DOES happen, I'll try to look deeper.


--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.

More information about the Icecast mailing list