[MPlayer-users] swScale_MMX2 bug ?

[Nilmoni Deb]

Managed to reproduce the bug at last. Configured with --enable-debug
and SDL. Ran mplayer with '-v -vo x11 -fs -zoom'. Here's the gdb trace:


mplayer: swscale_template.c:2715: swScale_MMX2: Assertion `lastInLumBuf +
1 - srcSliceY >= 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 1024 (LWP 23890)]
0x403e4621 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x403e4621 in kill () from /lib/libc.so.6
#1  0x4001f26b in raise (sig=6) at signals.c:65
#2  0x403e5a53 in abort () from /lib/libc.so.6
#3  0x403dde12 in __assert_fail () from /lib/libc.so.6
#4  0x081598d7 in swScale_MMX2 (c=0x86b6e80, srcParam=0xbfffe520, 
    srcStrideParam=0xbfffe330, srcSliceY=16, srcSliceH=16, 
    dstParam=0xbfffe2d0, dstStrideParam=0xbfffe2c0) at
swscale_template.c:2715
#5  0x0807f70d in draw_slice (src=0xbfffe520, stride=0xbfffe330, w=352,
h=16, 
    x=0, y=16) at vo_x11.c:518
#6  0x08092987 in draw_slice (frame=0x8226458, src=0xbfffe520)
    at vd_libmpeg2.c:102
#7  0x080c94af in slice_process (picture=0x82c0780, code=2 '\002', 
    buffer=0x40636048
"K]P\004a2\210\224}qgG~\221\204LGD_\217/.\206oz\"2{8\220
\027\216\005C\003\2267/\237") at slice.c:1759
#8  0x08092cc3 in parse_chunk (sh=0x82bec38, code=2, 
    buffer=0x40636048
"K]P\004a2\210\224}qgG~\221\204LGD_\217/.\206oz\"2{8\220
\027\216\005C\003\2267/\237", framedrop=0)
    at vd_libmpeg2.c:215
#9  0x08092e29 in decode (sh=0x82bec38, data=0x40636008, len=1676,
flags=0)
    at vd_libmpeg2.c:278
#10 0x08090f6f in decode_video (sh_video=0x82bec38, start=0x40636008 "", 
    in_size=1676, drop_frame=0) at dec_video.c:182
#11 0x08068b6c in main (argc=7, argv=0xbffff8e4, envp=0xbffff904)
    at mplayer.c:1546
#12 0x403d2280 in __libc_start_main () from /lib/libc.so.6

(gdb) disass $eip-32 $eip+32
Dump of assembler code from 0x403e4601 to 0x403e4641:
0x403e4601 <sigprocmask+65>:    or     $0xffffffff,%esi
0x403e4604 <sigprocmask+68>:    add    $0xc,%esp
0x403e4607 <sigprocmask+71>:    mov    %esi,%eax
0x403e4609 <sigprocmask+73>:    pop    %ebx
0x403e460a <sigprocmask+74>:    pop    %esi
0x403e460b <sigprocmask+75>:    pop    %edi
0x403e460c <sigprocmask+76>:    pop    %ebp
0x403e460d <sigprocmask+77>:    ret    
0x403e460e <sigprocmask+78>:    mov    %esi,%esi
0x403e4610 <kill>:      mov    %ebx,%edx
0x403e4612 <kill+2>:    mov    0x8(%esp,1),%ecx
0x403e4616 <kill+6>:    mov    0x4(%esp,1),%ebx
0x403e461a <kill+10>:   mov    $0x25,%eax
0x403e461f <kill+15>:   int    $0x80
0x403e4621 <kill+17>:   mov    %edx,%ebx
0x403e4623 <kill+19>:   cmp    $0xfffff001,%eax
0x403e4628 <kill+24>:   jae    0x403e462b <kill+27>
0x403e462a <kill+26>:   ret    
0x403e462b <kill+27>:   push   %ebx
0x403e462c <kill+28>:   call   0x403e4631 <kill+33>
0x403e4631 <kill+33>:   pop    %ebx
0x403e4632 <kill+34>:   xor    %edx,%edx
0x403e4634 <kill+36>:   add    $0x10c35b,%ebx
0x403e463a <kill+42>:   sub    %eax,%edx
0x403e463c <kill+44>:   push   %edx
0x403e463d <kill+45>:   call   0x403d1cb4 <SDL_alarm_callback+102892>
End of assembler dump.


Obviously, I am not using the SDL driver. Then why is it using the
SDL_alarm_callback function ?

I went into the SDL source tree and found by grep:

src/timer/SDL_timer.c:SDL_TimerCallback SDL_alarm_callback;
src/timer/SDL_timer.c:                  SDL_alarm_callback = callback;
src/timer/SDL_timer_c.h:extern SDL_TimerCallback SDL_alarm_callback;


thanks
- Nil