[Mjpeg-users] Update on: mpeg2enc current cvs segfault ?

[Richard E. <re...@ya...>]

I finally got a bit more time to fiddle, and I've got an update on
this segfault I reported at the beginning of the month.  The trouble
does indeed seem to lie with the machine I use for running mpeg2enc. 
I compiled a copy of rc92 on another machine and it worked just fine
there for me as well.  Then I thought I'd try compiling up a
statically linked mpeg2enc on that machine, and running it on the one
that does segfault.  The statically linked copy runs just fine on the
segfaulting machine, which would seem to rule out hardware influence. 
The only significant difference between the two is that on the
segfaulting machine, I'm still running glibc 2.1.2 (yes, arguably I
should upgrade, but anyway) while the machine that I compiled the
statically linked copy on has glibc 2.3.2 installed.  The compiler on
the machine where I made the static linked copy is gcc 2.95.3, the
same as the first compiler I tried that created the segfaulting
binary.  So I'm thinking there is some weirdness related to my
arguably quite old glibc 2.1.2 that is the source of the segfault
trouble.

As a secondary note, getting a statically linked mpeg2enc compiled
required a bit of makefile editing to include mpeg2enc libs on the
final mpeg2enc link call.  It wasn't hard to do, but it did take a
bit of investigating to determine which libs should link in.


On Fri, Nov 07, 2003 at 09:22:44AM -0500, Richard Ellis wrote:
> 
> Has anyone tried the current cvs mpeg2enc lately?  I pulled the
> current cvs on Nov. 4 because I wanted to see for myself how well the
> new "no B frames please" option worked.  But my copy of mpeg2enc
> compiled from the source I pulled that day takes a segfault while
> it's processing the first frame (field?).  Here is a gdb backtrace on
> the corefile that dumps when it segfaults:
> 
> Core was generated by `mpeg2enc.cvs.2003.11.04 -f 5 -n n -a 2 -V 230
> -B 224 -S 8000 -b 9576 -q 10 -I 1'.
> Program terminated with signal 11, Segmentation fault.
> [a bunch of symbol loading messages, cut for brevity]
> #0  quant_non_intra_sse (wsp=0x41778008, src=0x41a7b008, dst=0x41aec008, 
>     q_scale_type=1, satlim=2047, nonsat_mquant=0x41b5d02c)
>     at quantize_x86.c:309
> 309                     mulps_m2r( *(mmx_t*)&piqf[0], xmm2 );
> 
> The command line I was using to test this was the following:
> 
> lav2yuv t.cut | mpeg2enc.cvs.2003.11.04 -M 0 -f 5 -n n -a 2 -V 230 -B
> 224 -S 8000 -b 9576 -q 10 -I 1 -G 54 -H -N 0.0 -X 200 -Q 4.0 -d -4 4
> -2 4 -R 0 -o t.m2v
> 
> The binary was compiled with gcc 2.95.3, and all I did for the test
> binary was ./configure ; make.  I let it select all it's options. 
> The system is a P4 celeron (properly detected by configure) chip.
> 
> Did I happen to pull CVS while the source was "in transition" and
> that's why the segfault?
> 
> Thanks