Menu
▾
▴
[xine-bugs] [ xine-Bugs-1625339 ] --post eq2 causes SIGSEGV at eq2.c:126
|
From: SourceForge.net <no...@so...> - 2007-01-13 15:35:48
|
Bugs item #1625339, was opened at 2006-12-31 14:16 Message generated for change (Comment added) made by lorenzoedes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1625339&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: xine-lib Group: current cvs version Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: lorenzodes (lorenzoedes) Assigned to: Nobody/Anonymous (nobody) Summary: --post eq2 causes SIGSEGV at eq2.c:126 Initial Comment: $ uname -a Linux mediabox 2.6.18mmedia #1 PREEMPT Wed Sep 27 13:18:33 CEST 2006 x86_64 AMD Athlon(tm) 64 Processor 3000+ unknown GNU/Linux (gdb) run --no-splash --post eq2:brightness=1 -V xv -IBphq dvd:// Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1132489056 (LWP 6911)] 0x00002aaaae0ffe10 in affine_1d_MMX (par=0x1378e18, dst=0x2aabb0f0b8e8 <Address 0x2aabb0f0b8e8 out of bounds>, src=0x2aabb0e8c8e8 <Address 0x2aabb0e8c8e8 out of bounds>, w=720, h=238, dstride=360, sstride=360) at eq2.c:126 126 asm volatile ( (gdb) bt #0 0x00002aaaae0ffe10 in affine_1d_MMX (par=0x1378e18, dst=0x2aabb0f0b8e8 <Address 0x2aabb0f0b8e8 out of bounds>, src=0x2aabb0e8c8e8 <Address 0x2aabb0e8c8e8 out of bounds>, w=720, h=238, dstride=360, sstride=360) at eq2.c:126 #1 0x00002aaaae100fda in eq2_draw (frame=0x1458280, stream=0xcd50d0) at eq2.c:606 #2 0x00002aaab0bd931f in mpeg2_flush (mpeg2dec=0x13aa080) at decode.c:733 #3 0x00002aaab0bf1f5a in mpeg2dec_flush (this_gen=0x13aa050) at xine_decoder.c:91 #4 0x00002b07b3cd1d8a in video_decoder_loop (stream_gen=0xcd50d0) at video_decoder.c:289 #5 0x00002b07b405e0ea in start_thread () from /lib64/tls/libpthread.so.0 #6 0x00002b07b54ca3c3 in clone () from /lib64/tls/libc.so.6 #7 0x0000000000000000 in ?? () #8 0x0000000000000000 in ?? () [etc.] (gdb) disassemble $pc-0x10 $pc+0x10 Dump of assembler code from 0x2aaaae0ffe00 to 0x2aaaae0ffe20: 0x00002aaaae0ffe00 <affine_1d_MMX+335>: mov %eax,%eax 0x00002aaaae0ffe02 <affine_1d_MMX+337>: data16 0x00002aaaae0ffe03 <affine_1d_MMX+338>: data16 0x00002aaaae0ffe04 <affine_1d_MMX+339>: data16 0x00002aaaae0ffe05 <affine_1d_MMX+340>: nop 0x00002aaaae0ffe06 <affine_1d_MMX+341>: data16 0x00002aaaae0ffe07 <affine_1d_MMX+342>: data16 0x00002aaaae0ffe08 <affine_1d_MMX+343>: data16 0x00002aaaae0ffe09 <affine_1d_MMX+344>: nop 0x00002aaaae0ffe0a <affine_1d_MMX+345>: data16 0x00002aaaae0ffe0b <affine_1d_MMX+346>: data16 0x00002aaaae0ffe0c <affine_1d_MMX+347>: nop 0x00002aaaae0ffe0d <affine_1d_MMX+348>: data16 0x00002aaaae0ffe0e <affine_1d_MMX+349>: data16 0x00002aaaae0ffe0f <affine_1d_MMX+350>: nop 0x00002aaaae0ffe10 <affine_1d_MMX+351>: movq (%rbx),%mm1 0x00002aaaae0ffe13 <affine_1d_MMX+354>: movq (%rbx),%mm2 0x00002aaaae0ffe16 <affine_1d_MMX+357>: punpcklbw %mm0,%mm1 0x00002aaaae0ffe19 <affine_1d_MMX+360>: punpckhbw %mm0,%mm2 0x00002aaaae0ffe1c <affine_1d_MMX+363>: psllw $0x4,%mm1 End of assembler dump. Same problem happens with older versions of xine-lib (including 1.1.2 and 1.1.3). On another 32 bit PC eq2 works as expected. I don't know if it is relevant, but I have also compiled and built mplayer on my 64bit box and its eq2 filter works fine. ---------------------------------------------------------------------- >Comment By: lorenzodes (lorenzoedes) Date: 2007-01-13 15:35 Message: Logged In: YES user_id=1655097 Originator: YES Fixed. Strange it doesn't bomb on my AMD32 box. I wish Nvidia hadn't crippled the overlay on the 6x00 cards, this plugin is soooo slow :( Patch follows: --- eq2.c 2007-01-13 16:30:29.000000000 +0100 +++ xine-lib/src/post/planar/eq2.c 2007-01-13 16:31:58.000000000 +0100 @@ -599,12 +599,12 @@ pthread_mutex_lock (&this->lock); for (i = 0; i < 3; i++) { - int height; + int height, width; height = (i==0) ? frame->height : frame->height/2; - + width = (i==0) ? frame->width : frame->width/2; if (eq2->param[i].adjust != NULL) { eq2->param[i].adjust (&eq2->param[i], out_frame->base[i], yv12_frame->base[i], - frame->width, height, out_frame->pitches[i], yv12_frame->pitches[i]); + width, height, out_frame->pitches[i], yv12_frame->pitches[i]); } else { xine_fast_memcpy(out_frame->base[i],yv12_frame->base[i], ---------------------------------------------------------------------- Comment By: lorenzodes (lorenzoedes) Date: 2007-01-13 14:14 Message: Logged In: YES user_id=1655097 Originator: YES After a bit of digging I believe the problem arises somewhere in eq2_draw(vo_frame_t *frame, xine_stream_t *stream). Specificly, there's a loop that "adjusts" each plane composing the YV12 image. Whilst it succeeds with the first plane, it fails with the second, throwing the exceptions reported in my previous posts. Does this help in some way? ---------------------------------------------------------------------- Comment By: lorenzodes (lorenzoedes) Date: 2007-01-08 17:52 Message: Logged In: YES user_id=1655097 Originator: YES Is there any known issue with xine, MMX and a x86_64 AMD CPU? After updating to the current CV, I am getting an error that seems related without the --post eq2 flag. Here it is: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1132489056 (LWP 2041)] 0x00002aaaabf39f10 in put_h264_chroma_mc4_mmx (dst=0x2aaab03f2e24 '\200' <repeats 200 times>..., src=0x2aaab11f70a2 <Address 0x2aaab11f70a2 out of bounds>, stride=640, h=8, x=5, y=0) at dsputil_h264_template_mmx.c:235 235 asm volatile( (gdb) bt #0 0x00002aaaabf39f10 in put_h264_chroma_mc4_mmx (dst=0x2aaab03f2e24 '\200' <repeats 200 times>..., src=0x2aaab11f70a2 <Address 0x2aaab11f70a2 out of bounds>, stride=640, h=8, x=5, y=0) at dsputil_h264_template_mmx.c:235 #1 0x00002aaaabd1f1a2 in mc_dir_part (h=0x2aaaafedf010, pic=0x2aaaaff18b48, n=4, square=0, chroma_height=8, delta=10240, list=1, dest_y=0x2aaab0399148 " \037 ", '\037' <repeats 194 times>..., dest_cb=0x2aaab03f1ca4 "\177\177\177\177", '\200' <repeats 196 times>..., dest_cr=0x2aaab03c74a4 '\200' <repeats 200 times>..., src_x_offset=164, src_y_offset=264, qpix_op=0x2aaaafee0670, chroma_op=0x2aaaabf39e1f <put_h264_chroma_mc4_mmx>) at h264.c:2921 #2 0x00002aaaabd1ed09 in mc_part_std (h=0x2aaaafedf010, n=4, square=0, chroma_height=8, delta=10240, dest_y=0x2aaab0399148 " \037 ", '\037' <repeats 194 times>..., dest_cb=0x2aaab03f1ca4 "\177\177\177\177", '\200' <repeats 196 times>..., dest_cr=0x2aaab03c74a4 '\200' <repeats 200 times>..., x_offset=164, y_offset=264, qpix_put=0x2aaaafee0670, chroma_put=0x2aaaabf39e1f <put_h264_chroma_mc4_mmx>, qpix_avg=0x2aaaafee0870, chroma_avg=0x2aaaabf3a323 <avg_h264_chroma_mc4_mmx2>, list0=0, list1=32768) at h264.c:2958 #3 0x00002aaaabd1eab0 in mc_part (h=0x2aaaafedf010, n=4, square=0, chroma_height=8, delta=10240, dest_y=0x2aaab0399140 ' ' <repeats 11 times>, "\037 ", '\037' <repeats 186 times>..., dest_cb=0x2aaab03f1ca0 "\200\200\200\200\177\177\177\177", '\200' <repeats 192 times>..., dest_cr=0x2aaab03c74a0 '\200' <repeats 200 times>..., x_offset=4, y_offset=0, qpix_put=0x2aaaafee0670, chroma_put=0x2aaaabf39e1f <put_h264_chroma_mc4_mmx>, qpix_avg=0x2aaaafee0870, chroma_avg=0x2aaaabf3a323 <avg_h264_chroma_mc4_mmx2>, weight_op=0x2aaaafee0e00, weight_avg=0x2aaaafee0e50, list0=0, list1=32768) at h264.c:3045 #4 0x00002aaaabd1e2cb in hl_motion (h=0x2aaaafedf010, dest_y=0x2aaab0399140 ' ' <repeats 11 times>, "\037 ", '\037' <repeats 186 times>..., dest_cb=0x2aaab03f1ca0 "\200\200\200\200\177\177\177\177", '\200' <repeats 192 times>..., dest_cr=0x2aaab03c74a0 '\200' <repeats 200 times>..., qpix_put=0x2aaaafee05f0, chroma_put=0x2aaaafee05a8, qpix_avg=0x2aaaafee07f0, chroma_avg=0x2aaaafee05d8, weight_op=0x2aaaafee0df0, weight_avg=0x2aaaafee0e40) at h264.c:3096 #5 0x00002aaaabd22db5 in hl_decode_mb (h=0x2aaaafedf010) at h264.c:3792 #6 0x00002aaaabd53b5e in decode_slice (h=0x2aaaafedf010) at h264.c:7483 #7 0x00002aaaabd54b3f in decode_nal_units (h=0x2aaaafedf010, buf=0x13fddd0 "", buf_size=13744) at h264.c:8158 #8 0x00002aaaabd563c8 in decode_frame (avctx=0x13b60b0, data=0x13b5f90, data_size=0x4380606c, buf=0x13fddd0 "", buf_size=13744) at h264.c:8327 #9 0x00002aaaabee3126 in avcodec_decode_video (avctx=0x13b60b0, picture=0x13b5f90, got_picture_ptr=0x4380606c, buf=0x13fddd0 "", buf_size=13744) at utils.c:903 #10 0x00002aaaabc978b5 in ff_handle_buffer (this=0x2aaaafc3f010, buf=0xceb970) at video_decoder.c:1138 #11 0x00002aaaabc981fc in ff_decode_data (this_gen=0x2aaaafc3f010, buf=0xceb970) at video_decoder.c:1327 #12 0x00002af2f209c058 in video_decoder_loop (stream_gen=0xcd3f90) at video_decoder.c:375 #13 0x00002af2f24280ea in start_thread () from /lib64/tls/libpthread.so.0 #14 0x00002af2f367d3c3 in clone () from /lib64/tls/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) disassemble $pc-0x20 $pc+0x20 Dump of assembler code from 0x2aaaabf39ef0 to 0x2aaaabf39f30: 0x00002aaaabf39ef0 <put_h264_chroma_mc4_mmx+209>: std 0x00002aaaabf39ef1 <put_h264_chroma_mc4_mmx+210>: rorl 0x48142444(%rbx) 0x00002aaaabf39ef7 <put_h264_chroma_mc4_mmx+216>: cwtl 0x00002aaaabf39ef8 <put_h264_chroma_mc4_mmx+217>: mov %rax,%rdx 0x00002aaaabf39efb <put_h264_chroma_mc4_mmx+220>: lea 0x18(%rsp),%rax 0x00002aaaabf39f00 <put_h264_chroma_mc4_mmx+225>: add %rdx,(%rax) 0x00002aaaabf39f03 <put_h264_chroma_mc4_mmx+228>: mov 0x18(%rsp),%rdx 0x00002aaaabf39f08 <put_h264_chroma_mc4_mmx+233>: inc %rdx 0x00002aaaabf39f0b <put_h264_chroma_mc4_mmx+236>: mov 0x18(%rsp),%rax 0x00002aaaabf39f10 <put_h264_chroma_mc4_mmx+241>: movd (%rax),%mm0 0x00002aaaabf39f13 <put_h264_chroma_mc4_mmx+244>: movd (%rdx),%mm1 0x00002aaaabf39f16 <put_h264_chroma_mc4_mmx+247>: punpcklbw %mm7,%mm0 0x00002aaaabf39f19 <put_h264_chroma_mc4_mmx+250>: punpcklbw %mm7,%mm1 0x00002aaaabf39f1c <put_h264_chroma_mc4_mmx+253>: movq %mm0,%mm3 0x00002aaaabf39f1f <put_h264_chroma_mc4_mmx+256>: movq %mm1,%mm4 0x00002aaaabf39f22 <put_h264_chroma_mc4_mmx+259>: pmullw %mm6,%mm3 0x00002aaaabf39f25 <put_h264_chroma_mc4_mmx+262>: pmullw 0x30(%rsp),%mm4 0x00002aaaabf39f2a <put_h264_chroma_mc4_mmx+267>: paddw %mm3,%mm2 0x00002aaaabf39f2d <put_h264_chroma_mc4_mmx+270>: paddw %mm4,%mm2 End of assembler dump. Anything else I can provide to help get this bug fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1625339&group_id=9655 |