[icecast-dev] iceS 0.2.2 bug?

[Rob Pfile]

I havent had the time to look into this further, and since i'm not a
much of a C progammer, i'm afraid i might never figure it out so i
thought i'd report it here.

i'm running icecast 1.3.11 and feeding it with iceS 0.2.2. i've got 7
streams running, each running a different playlist out of my
collection in random order. one of the streams runs for a few hours
and then crashes. when i ran that stream in playlist order i found it
would crash while streaming a particular file, so i removed that file,
started the stream again, and it crashed later in the playlist. so i
removed *that* file and started again, and this time it crashed much
earlier in the playlist. my .mp3s check out ok using mp3_check, so i
dont think there's any file corruption, and i have to conclude maybe
there's a bug in icesS-0.2.2.

running the corefile thru gdb, i see that we've died here:

(gdb) where
#0  0x10018814 in shout_send_data (self=0x100c12c8, buff=0x7fffe0e8 "\212è", 
    len=1) at shout.c:180
#1  0x100128fc in stream_send_data (stream=0x100c12c8, buf=0x7fffe0e8 "\212è", 
    len=1) at stream.c:339
#2  0x1001260c in stream_send (source=0x7ffff538) at stream.c:213
#3  0x10012458 in ices_stream_loop () at stream.c:121
#4  0x10010f04 in main (argc=0, argv=0x3) at ices.c:41
#5  0xfe2e734 in __libc_start_main (argc=16, argv=0x7ffff9e4, envp=0x7ffffa28, 
    auxvec=0x7ffffa90, rtld_fini=0, stinfo=0x10096840, 
    stack_on_entry=0x7ffffffd) at ../sysdeps/powerpc/elf/libc-start.c:106

as you can see, shout_send_data was called with len=1. pos=0x1f15, and
so 

        while (pos <= (len - 4)) {
                /* find mp3 header */
                head = (buff[pos] << 24) | 
                       (buff[pos + 1] << 16) |
                       (buff[pos + 2] << 8) |
                       (buff[pos + 3]);

(pos <= len - 4) is now true, since len - 4 wrapped around.

(gdb) print buff
$9 = (unsigned char *) 0x7fffe0e8 "\212è"

but buff+pos+3 is 0x80000000, which gives me a segfault.

i guess pos was not supposed to be word aligned, or the code to pick
out the bytes and or them together wouldnt be there? but it seems like
the assumption was that len would always be >= 4. browsing thru the
code, it seems that len will be 4K for a while until the end of the
song is reached, at which point it will be some value < 4K, but that
value could be anything....

any help is appreciated.

thanks,

rob

--- >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-dev-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.