Nick Ludlam
2004-Aug-06 14:22 UTC
[icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10
Hi, got a little problem with the current cvs version of ices. I'm invoking it with the following: ices -v -F /home/nick/icetest.pls -h localhost -P <my password> which seems to connect ok, get past password validation, and gives me the following: DEBUG: Sending following information to libshout: DEBUG: Stream: 0 DEBUG: Host: localhost Port: 8000 DEBUG: Password: hack Icy Compat: 0 DEBUG: Name: Default stream name URL: http://www.icecast.org/ DEBUG: Genre: Default genre Desc: Default description DEBUG: Bitrate: 128 Public: 1 DEBUG: Mount: /ices Dumpfile: (null) Logfile opened DEBUG: Initializing playlist handler... DEBUG: Initializing builting playlist handler... Mounted on http://127.0.0.1:8000/ices DEBUG: Builtin playlist handler serving: /home/nick/hybrid-chamjam-080301.mp3 DEBUG: Layer: III Version: MPEG-1 Frequency: 44100 DEBUG: Bitrate: 128 kbit/s Padding: 0 Mode: stereo DEBUG: Ext: 0 Mode_Ext: 0 Copyright: 0 Original: 0 DEBUG: Error Protection: 0 Emphasis: 0 Stereo: 2 Playing /home/nick/hybrid-chamjam-080301.mp3 DEBUG: Initially delaying metadata update... Segmentation fault (core dumped) And Icecast's logfile gives the following: -> [09/Jul/2001:19:48:59] Accepted encoder on mountpoint /ices from 127.0.0.1. 1 sources connected -> [09/Jul/2001:19:48:59] Lost connection to source on mount /ices, waiting 30 seconds for timeout -> [09/Jul/2001:19:49:29] Kicking source 1 [127.0.0.1] [Client timeout exceeded, removing source] [encoder], connected for 30 seconds, 0 bytes transfered. 0 sources connected -> [09/Jul/2001:19:49:29] Kicking all 0 clients for source 1 So I've run the corefile through gdb and see the following backtrace: #0 0x401782d6 in __swsetup () #1 0x40172284 in vfprintf () #2 0x4017202d in fprintf () #3 0x91c1 in log_write (log_id=-1, priority=3, cat=0x76e4 "thread/_start_routine", fmt=0x76bc "Added thread %d [%s] started at [%s:%d]") at log.c:162 #4 0x77a2 in _start_routine (arg=0x180e0) at thread.c:536 #5 0x4002ff88 in _thread_start () at /usr/src/lib/libpthread/../libc_r/uthread/uthread_create.c:212 #6 0x17 in ?? () Cannot access memory at address 0xffffffff. So does this mean that ices is dieing somewhere in libc? At this point my knowledge of how to go further in debugging ices falls short. ktracing the output doesn't show anything particularly useful. I'm running this on a fairly standard x86-based openbsd 2.9 box, with icecast from the ports collection. Does anyone have any helpful suggestions? Many thanks, Nick -- Nick Ludlam - nick@recoil.org --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Nick Ludlam
2004-Aug-06 14:22 UTC
[icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10
Not got to the bottom of it yet, but commenting out both LOG_INFO lines in thread/thread.c stops it segfaulting. Now I'm back to the old problem of a 128k stream not being sent fast enough to the clients. Nick ----- Original Message ----- From: "Nick Ludlam" <nick@ivision.co.uk> To: <icecast@xiph.org> Sent: Monday, July 09, 2001 8:54 PM Subject: [icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10> Hi, > got a little problem with the current cvs version of ices. I'm invoking it > with the following: > > ices -v -F /home/nick/icetest.pls -h localhost -P <my password> > > which seems to connect ok, get past password validation, and gives > me the following: > > DEBUG: Sending following information to libshout: > DEBUG: Stream: 0 > DEBUG: Host: localhost Port: 8000 > DEBUG: Password: hack Icy Compat: 0 > DEBUG: Name: Default stream name URL: http://www.icecast.org/ > DEBUG: Genre: Default genre Desc: Default description > DEBUG: Bitrate: 128 Public: 1 > DEBUG: Mount: /ices Dumpfile: (null) > Logfile opened > DEBUG: Initializing playlist handler... > DEBUG: Initializing builting playlist handler... > Mounted on http://127.0.0.1:8000/ices > DEBUG: Builtin playlist handler serving: /home/nick/hybrid-chamjam-080301.mp3 > DEBUG: Layer: III Version: MPEG-1 Frequency: 44100 > DEBUG: Bitrate: 128 kbit/s Padding: 0 Mode: stereo > DEBUG: Ext: 0 Mode_Ext: 0 Copyright: 0 Original: 0 > DEBUG: Error Protection: 0 Emphasis: 0 Stereo: 2 > Playing /home/nick/hybrid-chamjam-080301.mp3 > DEBUG: Initially delaying metadata update... > Segmentation fault (core dumped) > > > And Icecast's logfile gives the following: > > -> [09/Jul/2001:19:48:59] Accepted encoder on mountpoint /ices from 127.0.0.1. 1 sources connected > -> [09/Jul/2001:19:48:59] Lost connection to source on mount /ices, waiting 30 seconds for timeout > -> [09/Jul/2001:19:49:29] Kicking source 1 [127.0.0.1] [Client timeout exceeded, removing source] [encoder], connected for 30 > seconds, 0 bytes transfered. 0 sources connected > -> [09/Jul/2001:19:49:29] Kicking all 0 clients for source 1 > > So I've run the corefile through gdb and see the following backtrace: > > #0 0x401782d6 in __swsetup () > #1 0x40172284 in vfprintf () > #2 0x4017202d in fprintf () > #3 0x91c1 in log_write (log_id=-1, priority=3, cat=0x76e4 "thread/_start_routine", fmt=0x76bc "Added thread %d [%s] started at > [%s:%d]") at log.c:162 > #4 0x77a2 in _start_routine (arg=0x180e0) at thread.c:536 > #5 0x4002ff88 in _thread_start () at /usr/src/lib/libpthread/../libc_r/uthread/uthread_create.c:212 > #6 0x17 in ?? () > Cannot access memory at address 0xffffffff. > > > So does this mean that ices is dieing somewhere in libc? At this point my knowledge > of how to go further in debugging ices falls short. ktracing the output doesn't show anything > particularly useful. I'm running this on a fairly standard x86-based openbsd 2.9 box, with > icecast from the ports collection. > > Does anyone have any helpful suggestions? > > Many thanks, > Nick > > -- > Nick Ludlam - nick@recoil.org > > > > > --- >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@xiph.org' > containing only the word 'unsubscribe' in the body. No subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. >--- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Brendan Cully
2004-Aug-06 14:22 UTC
[icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10
On Tuesday, 10 July 2001 at 01:26, Nick Ludlam wrote:> Not got to the bottom of it yet, but commenting out both LOG_INFO > lines in thread/thread.c stops it segfaulting. Now I'm back to the old problem > of a 128k stream not being sent fast enough to the clients.you should just be able to increase STACKSIZE in thread/thread.c from 8192 to 65536. The default stack size is too small, but linux/glibc always seem to give you much more than you ask for so it doesn't get noticed. This will be in 0.2.1 to be released shortly. That handles the segfault, I don't know why the stream wouldn't be sent fast enough though... Of course ices hasn't had a proper security audit. Please check with Theo de Raadt before running it. :) -Brendan --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.