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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.