Icecast dev - Oct 2004 - Icecast 2.0.1 segmentation fault under LInux

Hi:

I maintain an Icecast server at acbradio.org.  Recently it's been crashing 
fairly regularly.  I've not yet upgraded it to 2.0.2.  I thought I'd
report
this crash bug first as the release note seemed to suggest that the fix 
there was only for Windows.  I'm thinking that either this is a separate 
problem or it's an example of the same one under LInux, thereby making it 
moer important for *nix users to upgrade than the release note suggested.

Here's GDB's output:

[New Thread 88151 (LWP 11848)]
[New Thread 89176 (LWP 11849)]
[New Thread 90201 (LWP 12075)]
[New Thread 91226 (LWP 12076)]
[New Thread 92251 (LWP 12091)]
[New Thread 93276 (LWP 12092)]
[New Thread 94301 (LWP 16133)]
[New Thread 95326 (LWP 16134)]
[New Thread 96351 (LWP 16146)]
[New Thread 97376 (LWP 16147)]
[New Thread 98401 (LWP 16192)]
[New Thread 99426 (LWP 16193)]
[New Thread 100451 (LWP 16207)]
[New Thread 101476 (LWP 7430)]
[New Thread 102501 (LWP 7432)]
[New Thread 103526 (LWP 7487)]
[New Thread 104551 (LWP 7488)]
[New Thread 105576 (LWP 7523)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8201 (LWP 384)]
_handle_get_request (con=0xe86b95a4, parser=0x814f680, uri=0x81854e0
"/")
     at connection.c:720
720             if(global.serversock[i] == con->serversock) {
(gdb) info threads
   105 Thread 105576 (LWP 7523)  0x40346bb0 in poll () from /lib/libc.so.6
   104 Thread 104551 (LWP 7488)  0x40346bb0 in poll () from /lib/libc.so.6
* 10 Thread 8201 (LWP 384)  _handle_get_request (con=0xe86b95a4,
     parser=0x814f680, uri=0x81854e0 "/") at connection.c:720
   9 Thread 7176 (LWP 383)  0x402a787e in sigsuspend () from /lib/libc.so.6
   8 Thread 6151 (LWP 382)  0x402a787e in sigsuspend () from /lib/libc.so.6
   7 Thread 5126 (LWP 381)  0x402a787e in sigsuspend () from /lib/libc.so.6
   6 Thread 4101 (LWP 380)  0x402a787e in sigsuspend () from /lib/libc.so.6
   5 Thread 3076 (LWP 379)  0x4031ede1 in nanosleep () from /lib/libc.so.6
   4 Thread 2051 (LWP 378)  0x402a787e in sigsuspend () from /lib/libc.so.6
   3 Thread 1026 (LWP 377)  0x4031ede1 in nanosleep () from /lib/libc.so.6
   2 Thread 2049 (LWP 376)  0x40346bb0 in poll () from /lib/libc.so.6
   1 Thread 1024 (LWP 371)  0x40346bb0 in poll () from /lib/libc.so.6
(gdb) bt
#0  _handle_get_request (con=0xe86b95a4, parser=0x814f680, uri=0x81854e0
"/")
     at connection.c:720
#1  0x0804eec6 in _handle_connection (arg=0x494fffff) at connection.c:973
#2  0xfff8e805 in ?? ()
Cannot access memory at address 0xeb5903eb

I'm not an expert with regard to debugging.  I've still got the session 
open in GDB and want to know if there's any more info you want or need 
before I kil it off and restart.

Oh and the logs don't appear to show anything useful.

Geoff.

On Wednesday 06 October 2004 09:32, Geoff Shang wrote:
> Hi:
>
> I maintain an Icecast server at acbradio.org.  Recently it's been
crashing
> fairly regularly.  I've not yet upgraded it to 2.0.2.  I thought
I'd report
> this crash bug first as the release note seemed to suggest that the fix
> there was only for Windows.  I'm thinking that either this is a
separate
> problem or it's an example of the same one under LInux, thereby making
it
> moer important for *nix users to upgrade than the release note suggested.
>
> _handle_get_request (con=0xe86b95a4, parser=0x814f680, uri=0x81854e0
"/")
>      at connection.c:720
> 720             if(global.serversock[i] == con->serversock) {
Geoff,

This looks like something that should be "impossible". It's almost
certainly
memory corruption somewhere - and so the bug is probably somewhere else 
entirely, nowhere near this code. 

Do you have any way to reproduce this on demand? Or is it just something that 
happens apparently randomly?

Upgrading to 2.0.2 is a good idea - I can't guarantee it'll help, but
it's
definately worth a try.

If it doesn't help, any more information on how to reproduce this would be 
really helpful. If running it under valgrind is possible (i.e. you're
running
linux on x86, and you have some cpu to spare), that might be worthwhile too.

Mike

Michael Smith wrote:
> This looks like something that should be "impossible". It's
almost certainly
> memory corruption somewhere - and so the bug is probably somewhere else
> entirely, nowhere near this code.
Oh great. :)
> Do you have any way to reproduce this on demand? Or is it just something
that
> happens apparently randomly?
Well I don't know.  I'd not had any problems at all until the last
couple
of weeks.  The server has crashed each day for the past few days.  This is 
the first time I've run it under GDB though.  I don't know if it's
random
or not, since there's no useful info in the logs that I can see (I've
kept
the logs though).  I can tell you that the last two times the server was p 
for the same amount of time (approximately), around 18.5 hours.

It's running against libogg 1.1 and libvorbis 1.0.1, if this helps.  Oh and 
curl 7.10.1.
> Upgrading to 2.0.2 is a good idea - I can't guarantee it'll help,
but it's
> definately worth a try.
Should I upgrade to libogg 1.1.2 and vorbis 1.1 as well?
> If it doesn't help, any more information on how to reproduce this would
be
> really helpful. If running it under valgrind is possible (i.e. you're
running
> linux on x86, and you have some cpu to spare), that might be worthwhile
too.
CPU is running pretty close to the mark up there, load average is usually 
over 2, since we run 6 streams up there plus the two vorbis ones running on 
the icecast server, and we have 4 LAME processes running as well as the two 
streamtranscoder processes which run these streams.  But it is running on 
x86 Linux.

So am I right in thinking that we can't glean anything more from this GDB 
session?  I'd really like to restart the server as soon as this is 
possible.

Geoff.

Michael Smith wrote:
> This looks like something that should be "impossible". It's
almost certainly
> memory corruption somewhere - and so the bug is probably somewhere else
> entirely, nowhere near this code.
Just to clarify my understanding, this would be something caused by code in 
Icecast or one of its dependent libs, not some other running process, 
right?  And whatever is doing this would only be corrupting Icecast memory 
and nothing accessed by any other app?  Or not?

Geoff.