[vlc-devel] segfault caused by who-knows-what
Cian Cullinan
cian.cullinan at gmail.com
Tue Jan 31 18:10:07 CET 2006
The following command line results in VLC segfaulting after a while
(from a few minutes to over an hour sometimes):
/usr/bin/vlc -vvv --no-mmxext --color -I telnet --telnet-password
blahblah --telnet-host localhost --telnet-port 4212 --vlm-conf
/data/movies/test/multicast_test03.vlm
where multicast_test03.vlm is:
new channel1 broadcast enabled loop
setup channel1 input /data/movies/test/Bannow.mp4
setup channel1 output
#standard{mux=ts,access=udp,url=239.255.1.1,sap,name="Channel 1"}
new channel2 broadcast enabled loop
setup channel2 input /data/movies/test/Mares.mp4
setup channel2 output
#standard{mux=ts,access=udp,url=239.255.1.2,sap,name="Channel 2"}
control channel1 play
control channel2 play
Doing a backtrace in gdb gives the following:
#0 0x080cf724 in fast_memcpy__memcpymmxext (to=0xb5499d40,
from=0xaf22eff3, len=46) at fastmemcpy.h:342
#1 0x080dfdbf in EStoPES__mux_ts (p_sout=0x9326a68,
pp_pes=0xb49fd0e0, p_es=Variable "p_es" is not available.
) at pes.c:306
#2 0x080dea16 in Mux (p_mux=0x932b188) at ts.c:1443
#3 0x00111eca in Send (p_stream=0x932a870, id=0x934c8b0,
p_buffer=0xb544a608) at standard.c:453
#4 0x0807ef23 in sout_InputSendBuffer (p_input=0x934c8a0,
p_buffer=0xb544a608) at src/stream_output/stream_output.c:276
#5 0x080ad488 in DecoderDecode (p_dec=0xb5403f98, p_block=0x0) at
src/input/decoder.c:579
#6 0x080b033b in EsOutSend (out=0x9329ee0, es=0xb5422238,
p_block=0xaf202288) at src/input/es_out.c:1084
#7 0x00c78aa3 in Demux (p_demux=0xb5409810) at
../../../include/vlc_es_out.h:108
#8 0x08065f4e in MainLoop (p_input=0xb5401e30) at src/input/input.c:527
#9 0x08066d8e in Run (p_input=0xb5401e30) at src/input/input.c:434
#10 0x00471341 in start_thread () from /lib/tls/libpthread.so.0
#11 0x0035d6fe in clone () from /lib/tls/libc.so.6
and "frame 0" reports:
#0 0x080cf724 in fast_memcpy__memcpymmxext (to=0xb5499d40,
from=0xaf22eff3, len=46) at fastmemcpy.h:342
342 __asm__ __volatile__ (
Talking with some people on IRC it was thought that VLC was using CPU
MMX EXT when it shouldn't (the machine is a dual proc Xeon, and there
is no mention of mmxext in /proc/cpuinfo), but I get the same results
when running the above command line with the --no-mmxext option.
The machine in question is running CentOS 4.2, and VLC snapshot from
2006-01-29, and ffmpeg SVN code from 2006-01-03.
VLC was compiled on my laptop with a Pentium M processor.
The two files it is multicasting are MPEG4/AAC, about 4096kb, encoded
in Quicktime Pro.
I have not seen this problem with a couple of lower bandwidth movie
files, also MPEG/AAC when they have been running for several days.
Anyone have any ideas?
Cian
P.S. my config line for compiling VLC:
./configure \
--x-libraries=/usr/X11R6/lib \
--enable-release \
--enable-livedotcom --with-livedotcom-tree=live \
--enable-ffmpeg --with-ffmpeg-tree=ffmpeg-20060103 \
--enable-faad --with-faad-tree=faad2-20040923 \
--enable-mozilla \
--enable-faad \
--enable-dvbpsi \
--disable-dvdread \
--disable-hal \
--disable-dvdnav \
--disable-smb \
--disable-gnomevfs \
--disable-libcdio \
--disable-libcddb \
--disable-cdda \
--disable-vcd \
--disable-screen \
--disable-mkv \
--disable-mod \
--disable-mpc \
--disable-dts \
--disable-speex \
--disable-x264 \
--disable-cmml \
--disable-glx \
--disable-opengl \
--disable-fribidi \
--disable-sdl \
--disable-skins2 \
--disable-hd1000v \
--disable-hd1000a \
--disable-fb \
--disable-wxwidgets \
--disable-visual \
--disable-daap \
--disable-bonjour
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel
mailing list