Icecast - Aug 2004 - YP submission / cURL issue. (icecast 2.0.1 / gentoo)

I've yet to assemble a valid crash-procedure to consistently re-produce the
issue. AFAIK, whats causing it is possibly CPU-utilization issues with my
chaining of processing/DSP, what do y'all think?! --  My encoder setup:

Winamp
  `[DSP] -> SoundSolution (dynamic sonic enhancement)
  `[Output] -> SqrSoft Crossfading (only ''REAL'' crossfader)
        `[SqrSoft DSP Emul]` -> (Sqrsoft HAS to be 'output' and then
MUX DSPs)
                  `[MuchFX 0.9902]
                        | 2x - Oddcast 2.0.13 -> Icecast
                        | 2x -   "       "    -> Shoutcast
                        | 2x -   "       "    -> Windows Media
  `[GenPurp] -> DoSomething (generate HTML to 'net mapped' web-server
drive)

<p><p>I've got a total of six encoders and all the others. On a 
song-transision / the
cross-fader will drive CPU dangerously high and I'm wondering if 
there's a loss
of avail CPU time, will OddCast possibly choke/stall and then cause the 
Icecast
crash? This is where I'd guess the issue of where the crash is. It's
almost
impossible to guess when it'll crash so I can't totally validate my 
assumption.
I know the encoder setup is not at all Icecast related, just the fact
there's
all the processing that drives CPU to 100% as well as the way SqrSoft 
does it's
crossfade with songs, the buffering mechanism is a little odd. Might want to
look at it if you're curious.

SoundSolution-- http://www.tmsweb.dnsalias.com
SqrSoft-- http://www.sqrsoft.com.ar
MuchFX-- http://sourceforge.net/project/showfiles.php?group_id=90732
OddCast-- http://www.oddsock.org/tools/oddcastv2_wa2

I don't see it happening on the (non-YP) Linux Icecast but it happens 
routinely
in Win32 Icecast.

<p>Quoting Michael Smith <msmith@xiph.org>:
> On Wednesday 26 May 2004 14:24, cpickert@t3inc.us wrote:
>
>>   I've been using the win32 icecast for ages now (which YP stuff
works
>> great) but am wanting to move to the *nix[linux now via gentoo] variant
as
>> I've been having troubles where icecast was crashing routinely and
would
>> actually chain-crash my OddSock->Winamp on the encoder and if Winamp
>> crashed from a non-oddsock error, sometimes the icecast sever would
crash
>> with it. Terrible stuff but I talked with Monty about it at SXSW and
have
>> seen that 2.0.1 itself was released (by OddSock) to fix crashes related
to
>> buffer overflows, but I've still experienced the issues.
>>
>
> It really shouldn't do that. The 2.0.1 release was for a single 
> overflow (that
> would never happen accidently - only through a deliberate attack), so I
> wouldn't expect that to help. However, if it's crashing, we'd
really like to
> know about that - with enough details to reproduce (and hopefully fix).
>
> Mike
>
> --- >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.
<p>--- >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.

On Wednesday 26 May 2004 16:19, cpickert@t3inc.us wrote:
> I've got a total of six encoders and all the others. On a
> song-transision / the
> cross-fader will drive CPU dangerously high and I'm wondering if
> there's a loss
> of avail CPU time, will OddCast possibly choke/stall and then cause the
> Icecast
> crash? This is where I'd guess the issue of where the crash is.
It's almost
> impossible to guess when it'll crash so I can't totally validate my
> assumption.
> I know the encoder setup is not at all Icecast related, just the fact
> there's all the processing that drives CPU to 100% as well as the way
> SqrSoft does it's
> crossfade with songs, the buffering mechanism is a little odd. Might want
> to look at it if you're curious.
<p>Obviously, if you run out of CPU, it's not entirely unreasonable
for oddcast
to have trouble of some sort. However, there should be absolutely _no_ way 
for this to crash icecast. Icecast is designed to be error-resiliant and not 
particularly timing-sensitive. If you can find any way to reliably crash 
icecast, we really, really want to fix it (being able to crash it with 
external input is generally a sign that there's - at the least - an 
exploitable DoS bug lurking somewhere), so we'd really like as much detail
as
you can give us.

Mike

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

Mike:

Totally understood, I'll be doing my best. I spoke with Monty (Christopher
Montgomery via whois) at SXSW (South-by-SouthWest music/media 
conference) about
this exact issue. His immediate response dealt with the slightly differently
implementations of POSIX-esque non-blocking IO on nicely POSIX-friendly
OSs(Linux,*BSD) vs. Win32 ... It's been doing this for roughly a year (since
I
started w/ OddCast+IcecastWin32(OddSock build / Same as icecast.org ?) 
but with
no easily descernable activity leading up to the crash, other than the CPU
utilization nonsense I've already rambled on. (which might make my oddcast
poop, but never icecast itself -- although they ALWAYS occured together. As
soon as we noticed the WM stream die, we knew the encoder crapped, and we
ALWAYS had to restart the icecast-win32 server).

The only thing I'm ''stuck'' w/ now (as I definitely want to
assist you in
further exploration of the above) is that my Icecast cURL stuff is busted on
the Icecast 2.0.1 build in Linux/gentoo.. very bizarre.. I posted up the
original info back three posts. Any ideas on it? It's been replicated on two
gentoo boxes(tried different cURL versions, could it also be chroot? see
initial post if interested) I've also built it by hand via the 2.0.1 release
source tarball and came up w/ same results (same curl versions as listed in my
'equery' output from former posts.

Gotta have people knowing they can listen.. Especially since Real and iTunes
still can't get their stuff together for their players. Haven't tried
the new
Helix Player Alphas (but Real10 doesn't seem to play an Icecast or .ogg 
file)..
Has anyone?

-- chris pickert

Quoting Michael Smith <msmith@xiph.org>:

<p>> Obviously, if you run out of CPU, it's not entirely
unreasonable for oddcast
> to have trouble of some sort. However, there should be absolutely _no_ way
> for this to crash icecast. Icecast is designed to be error-resiliant and
not
> particularly timing-sensitive. If you can find any way to reliably crash
> icecast, we really, really want to fix it (being able to crash it with
> external input is generally a sign that there's - at the least - an
> exploitable DoS bug lurking somewhere), so we'd really like as much
detail as
> you can give us.
>
> Mike
--- >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.