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 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
