[icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10
nick at recoil.org
Mon Jul 9 17:26:50 PDT 2001
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.
----- Original Message -----
From: "Nick Ludlam" <nick at ivision.co.uk>
To: <icecast at xiph.org>
Sent: Monday, July 09, 2001 8:54 PM
Subject: [icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10
> 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 Ludlam - nick at 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 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.
--- >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