On 11/16/05, Adam Egger wrote: > > STATE: 4 (b5e5a082) W: 720 H: 576 P: 1080000 4:24:30.6 T:2 F: 2 > STATE: 0 (8374595) W: 720 H: 576 P: 1080000 4:24:29.19 T:2 F: 2 > STATE: 0 (8543db2) W: 720 H: 576 P: 1080000 4:24:29.19 T:0 F: 2 > STATE: 0 (825214a) W: 720 H: 576 P: 1080000 4:24:29.19 T:1 F: 2 > STATE: 0 (82ee515) W: 720 H: 576 P: 1080000 4:24:29.19 T:5 F: 2 > STATE: 0 (850cb92) W: 720 H: 576 P: 1080000 4:24:29.19 T:3 F: 2 > STATE: 0 (842a4ea) W: 720 H: 576 P: 1080000 4:24:29.19 T:4 F: 2 > STATE: 0 (83b1255) W: 720 H: 576 P: 1080000 4:24:29.19 T:8 F: 2 > STATE: 0 (83310b2) W: 720 H: 576 P: 1080000 4:24:29.19 T:6 F: 2 > STATE: 0 (837d652) W: 720 H: 576 P: 1080000 4:24:29.19 T:7 F: 2 > STATE: 0 (829f3ad) W: 720 H: 576 P: 1080000 4:24:29.19 T:11 F: 2 > STATE: 0 (846fef2) W: 720 H: 576 P: 1080000 4:24:29.19 T:9 F: 2 > > *** glibc detected *** double free or corruption (out): 0x083a1470 *** > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1225319584 (LWP 28235)] > 0xb75047a7 in raise () from /lib/tls/libc.so.6 > (gdb) bt > #0 0xb75047a7 in raise () from /lib/tls/libc.so.6 > #1 0xb750604b in abort () from /lib/tls/libc.so.6 > #2 0xb753b005 in __fsetlocking () from /lib/tls/libc.so.6 > #3 0xb7541657 in malloc_usable_size () from /lib/tls/libc.so.6 > #4 0xb7541af2 in free () from /lib/tls/libc.so.6 > #5 0x0804c9ea in MPEG2fixup::build_frame (this=0xbfea3bc0, > pkt=0xbfea378c, fname=0xbfea37c0 "cnv0.yuv") > at mpeg2fix.cpp:956 > #6 0x0804d105 in MPEG2fixup::convert_to_i (this=0xbfea3bc0, > frameNum=9, numFrames=3, headPos=9) at mpeg2fix.cpp:1222 > #7 0x080507d0 in MPEG2fixup::start (this=0xbfea3bc0) at mpeg2fix.cpp:1494 > #8 0x08051bfd in main (argc=14, argv=0xbfea4f34) at mpeg2fix.cpp:1806
This is odd. 1st I really need to see your full command line, as you appear to be applying a commercial-cut here, but I don't know what you actually chose. 2nd, while this debug is more interesting, it isn't very enlightening. There is really no way that I can see to get a double free on the codecContext (the free atline 956), which implies, perhaps, a stack overrun. I wonder if this is a segfault from libavcodec similar to what Bryan saw. What version of SVN are you running? You could try setting a break point at line 939 (at the avcodec_encode_video call) and doing something like this before and after the call: print c print outbuf print picture print out_size print outbuf_size print *c print *picture if any of the 1st 3 are different (the 0x????????, not any data afterwards), that is definitely stack corruption. The 6th and 7th commands will dump out a lot of text. I'm not particularly interested in the values, but you should spot-check that there are no whacky numbers. after that step through and ensure that it still dies on the 'free(c)' You could also try disabling all SSE, SSE2, etc by adding something like this at line 938 (before the encode_video call): c->dsp_mask = 0xffff; recompiling and rerun. Sorry I can't be of more help than that, but maybe something above will help us make some progress. .Geoff _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
