Hi On 08/02/2008, Geoff Shang <Geoff@quitelikely.com> wrote:> Hi, > > Anything helpful in your error.log? You may need to set the log level to 4 > (debug).Ok - I've had 5 seg faults in the last 24 hours which is a pain, as you can imagine. I crona script once per minute to restart Icecast in the event that it fails so the service is never down for more than 59 secs but it drops encoder/client connections in that time. However I now have some clues - preceding each seg fault I get this: [2008-02-10 18:36:10] INFO source/source_main listener count on /radiofm.mp3 now 0 [2008-02-10 18:36:10] DBUG admin/admin_handle_request Admin request (/admin/metadata) [2008-02-10 18:36:10] DBUG admin/admin_handle_request Got command (metadata) [2008-02-10 18:36:10] INFO admin/admin_handle_request Received admin command metadata on mount "/radiofm.mp3" [2008-02-10 18:36:10] DBUG admin/command_metadata Got metadata update request ^NS^S??7h_????R<86>''-10 18:36:10] INFO admin/command_metadata Metadata on mountpoint /radiofm.mp3 changed to ";V^^<90>LQZ????<90>g^C<8f>n%"U??&B??<9b>0di? <90><8d>^Y^Q<9c>&^]^Pl4^N^Y<89><9a><95><80>?Q???(R)?<8d><89>-;??<94>?????<8b>Y?????e<95><95>qwxn+?T<93>??a<97>?<9c>r???U??F$??<8a>?2+c?g6y7^V?<81>%???(R)??<9c>!<???<97>????W????" [2008-02-10 18:36:10] DBUG fserve/fserve_add_client Adding client to file serving engine [2008-02-10 18:37:01] INFO main/main Icecast 2.3.1 server started or here's another: [2008-02-11 06:44:11] INFO admin/command_metadata Metadata on mountpoint /radiofm.mp3 changed to ";<87>??&???s<8d>??^Db"^L?<96><82>??Ak???_^?)<94>??<8f>??<g$??<87>h????e<96>O^Gt??^N<9e>C?8?????3?(R)W?<90>??<94>^G??p??? ??@?????????????k}o????'w????????<98>b<88>???????^Q^A??n?^PSQL?<8e>M?" [2008-02-11 06:44:11] DBUG fserve/fserve_add_client Adding client to file serving engine [2008-02-11 06:45:01] INFO main/main Icecast 2.3.1 server started Currently looking at status.xsl at my rogue webcaster there entry for this chap is thus (names changed to protect the innocent/guilty): Stream Title: Radio FM Stream Description: Radio FM Bitrate: 32 Stream Listeners: 0 Stream Genre: Various Stream URL: http://path.to.my.server:8000/radiofm.mp3 Current Song: ?r?uX??s?7_?n??GYF???<+R???V%??(:?)??oE??pX??!k?)~?w?+c5?2O?1f??GhE?2*??xC?6?LzFH??"??/*???H5????G??,?L?7M?f?Z?? Listen: Click to Listen The stream plays fine but the song title is obviously borked. I have only recently switched to this new server setup (FC8, 2.6.23.9-85.fc8) and my previous instance of Icecast was not vulnerable to this problem - could this be something like I don't have Unicode/UTF8 installed? As my previous Icecast installation was not vulnerable to this issue, I think there must be something that can be done server side to accommodate this webcaster who is sending us this 'broken' metadata. Many thanks in advance for your help. Chip Scooter
chiapas@aktivix.org wrote:> Stream Title: Radio FM > Stream Description: Radio FM > Bitrate: 32 > Stream Listeners: 0 > Stream Genre: Various > Stream URL: http://path.to.my.server:8000/radiofm.mp3 > Current Song: ..... > Listen: Click to Listen > > The stream plays fine but the song title is obviously borked.unless Prince is having trouble again :)> I have only recently switched to this new server setup (FC8, > 2.6.23.9-85.fc8) and my previous instance of Icecast was not > vulnerable to this problem - could this be something like I don't have > Unicode/UTF8 installed?no, with 2.3.1, there was no modification to the actual string content. What you are seeing is either sent incorrectly or something in the server corrupted memory. The change in system can expose issues that have been missed, change in hardware could expose possible race cases.> As my previous Icecast installation was not vulnerable to this issue, > I think there must be something that can be done server side to > accommodate this webcaster who is sending us this 'broken' metadata.Can you try out the trunk code?, a source tarball is available at http://people.xiph.org/~brendan/snapshots/icecast/ build with make debug and run with catchsegv if it still shows the problem. karl.
hi i had meant to email back the list with an update to my Icecast issue but emailed Karl directly instead. for the sake of completeness i have my email and Karl's latest reply below. On 12/02/2008, Karl Heyes <karl@xiph.org> wrote:> chiapas@aktivix.org wrote: > > hi > > > > On 11/02/2008, Karl Heyes <karl@xiph.org> wrote: > >> Can you try out the trunk code?, a source tarball is available at > >> http://people.xiph.org/~brendan/snapshots/icecast/ build with make > >> debug and run with catchsegv if it still shows the problem. > > > > i've got in touch with my 'rogue' user and got them to reinstall > > Oddcast and all's fine for now. however i am still slightly concerned > > that my set-up remains vulnerable to this problem - is it a buffer > > overflow issue? i am reluctant to install the trunk code as it will > > mean another service outage for my users and the seg faults have given > > us quite a few of those recently... > > > It's impossible for me to say, based on the report you gave, what the > exact cause is. There has been at least one buffer length related issue > resolved but I've never seen it appear like that, however there has been > a number of race case fixes which have unpredictable effects. For me to > try to confirm the cause would mean for you give me the stack trace of a > debug build of icecast, which I'm guessing you would to be built and > then swapped into place. > > The difference between that and using trunk is not that big as the > changes to trunk have been kept small. I'd get the latest trunk work, > do a make debug build then wait for an appropriate time to swap into > place (crash, quiet time etc). You could do a parallel run on a > different port to make sure the xml is fine before hand (just copy the > xml and change port and log dir). > > As I said before, as developers we would need a stack trace which means > either getting a core file or using catchsegv to report the stack trace > when the crash occurs. > > eg catchsegv /path/to/icecast -c /path/to/icecast.xml > out.txt > > > karl.many thanks for this Karl. i cannot recreate this error as i contacted the webcaster and, with their permission, remotely logged onto their machine and fixed their set-up of Winamp/Oddcast. i will keep vigilant for the same error and implement the above suggestions to generate a stack trace in the event of the same problem occuring. thanks again for your swift and helpful responses all. regards Chip Scooter