[icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10

[Nick Ludlam]

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

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