Just following up... I was playing with this some more, and a friend was
able to reproduce the error. His stack trace is:
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -1211504960 (LWP 15433)]
0xb7dc698c in send () from /lib/tls/libpthread.so.0
(gdb) bt
#0 0xb7dc698c in send () from /lib/tls/libpthread.so.0
#1 0xb7f59a41 in _shout_sock_write_bytes (sock=6, buff=0xbff93030,
len=3086350260) at sock.c:334
#2 0xb7f578b9 in try_write (self=0x8057f38, data=0x8069964, len=30) at
shout.c:1017
#3 0xb7f5653c in shout_send_raw (self=0x8057f38, data=0x8069964
"\001vorbis", len=30) at shout.c:209
#4 0xb7f58d8f in send_page (self=0x8057f38, page=0xbff930f0) at ogg.c:199
#5 0xb7f58ad2 in send_ogg (self=0x8057f38, data=0xbff93170 "OggS",
len=134649352) at ogg.c:133
#6 0xb7f5647a in shout_send (self=0x8057f38, data=0xbff93170 "OggS",
len=4096) at shout.c:192
#7 0x08049d88 in streamFile (shout=0x8057f38, song=0x8057f20) at
ezstream.c:278
#8 0x0804a246 in main (argc=134577952, argv=0x8057f38) at ezstream.c:497
Here's my stack trace:
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -1208215872 (LWP 27780)]
0x005fd7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) thread apply all bt
Thread 1 (Thread -1208215872 (LWP 27780)):
#0 0x005fd7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x0087e8f1 in send () from /lib/tls/libpthread.so.0
#2 0x006b367c in _shout_sock_write_bytes (sock=6, buff=0x898b1b8,
len=60) at sock.c:334
#3 0x006b0fb0 in try_write (self=0x8978040, data=0x898b1b8, len=60) at
shout.c:1012
#4 0x006b11ba in shout_send_raw (self=0x8978040, data=0x898b1b8
"OggS",
len=60) at shout.c:209
#5 0x006b285d in send_ogg (self=0x8978040, data=0xbfe0c4d0, len=4096)
at ogg.c:196
#6 0x006b1129 in shout_send (self=0x8978040, data=0xbfe0c4d0, len=4096)
at shout.c:192
#7 0x08049cf8 in streamFile (shout=0x8978040, song=0x89782d8) at
ezstream.c:278
#8 0x0804a4af in main (argc=3, argv=0xbfe0d5d4) at ezstream.c:497
We must have slightly differing versions of libshout as the line numbers
don't agree. You can see error occurs in the same place thought I'm not
sure if the reason for the error is the same in both cases. Any
assistance or insight on this would be great, thanks.
Chris
Chris MacDonald wrote:> Hi,
>
> I've been working on a customized version of ezstream and I've been
> noticing that with a particular setup after playing particular tracks
> ezstream terminates. I say terminates because there are no error
> messages, it just exits. I've tried this on both my version and the
> stock version available via icecast.org just be certain and it happens
> with both versions.
>
> I'm running:
> icecast 2.3.1
> ezstream 0.2.1
> flac 1.1.2
> oggenc 1.0.2 (vorbis-tools 1.1.1)
> libogg 1.1.3
> libvorbis 1.1.2
>
> Currently I have ezstream set up to re-encode from my flac library to
> ogg, and with a couple tracks (it's always the same ones) it will make
> it all the way through then hang at the end of the track for a second
> or two then ezstream will exit. When I go from flac to lame on those
> tracks it's fine. One thing that the tracks in question have in common
> is that they're all longer than the average song, usually >7
minutes.
> I've tried re-encoding at the command line using the same command as
> ezstream and a valid track is produced without error. I've also gone
> through and taken valgrind and used it against my version of ezstream
> to make sure there aren't any leaks and even running with valgrind
> ezstream appears as though it terminates cleanly after playing a
> particular track.
>
> I really don't know what else to do. If I had an error message I might
> have an idea as to where to start looking, alas I don't. Little help?
;D
>
> Thanks,
> Chris
> _______________________________________________
> Icecast mailing list
> Icecast@xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast