[MPlayer-users] Error occurring on q or >, not sure if mplayer or not
stan
RegBur_Flydan8 at q.com
Mon Oct 1 23:52:22 CEST 2012
On Sat, 29 Sep 2012 20:39:11 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> On Thu, Sep 27, 2012 at 01:38:02PM -0700, stan wrote:
> > It seems to be a problem with nouveau. The output is large, but
> > here it is:
> >
> > Program received signal SIGSEGV, Segmentation
> > fault. 0x00007fffebf4fb96 in nouveau_grobj_autobind ()
> > from /lib64/libdrm_nouveau.so.1 Missing separate debuginfos, use:
> > debuginfo-install libXcursor-1.1.13-1.fc17.x86_64
> > libXrender-0.9.7-1.fc17.x86_64 mesa-dri-drivers-8.0.4-1.fc17.x86_64
> > (gdb) bt #0 0x00007fffebf4fb96 in nouveau_grobj_autobind ()
> > from /lib64/libdrm_nouveau.so.1
>
> Yes, I think it is likely that is a bug in nouveau code, though
> installing the debug packaged for it and maybe even running
> through valgrind might give more useful information.
>
Well, running valgrind is easy, interpreting the output, and having
confidence in my interpretation, not so much.
$ valgrind --tool=memcheck --leak-check=full --track-origins=yes mplayer -nosound Walter_Futter_Africa_Speaks_1930.avi
Originally, I ran the above command. It stopped the program with an
error shortly after the video display came up. The error seemed to be
in a faulty jump command. Here is the relevant output.
Starting playback...
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
[swscaler @ 0x1072b40]using unscaled yuv420p -> bgra special converter
VO: [gl] 640x480 => 640x480 BGRA
==9190== Syscall param ioctl(generic) points to uninitialised byte(s)
==9190== at 0x3C046EA2F7: ioctl (in /usr/lib64/libc-2.15.so)
==9190== by 0x3C126035F7: drmIoctl (in /usr/lib64/libdrm.so.2.4.0)
==9190== by 0x10D85140: ??? (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9190== by 0x10D8529B: nouveau_bo_ref (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9190== by 0x10D841AF: ??? (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9190== by 0x10D8464F: nouveau_pushbuf_flush (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9190== by 0x107AC6AB: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9190== by 0x107ADA88: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9190== by 0x10957CEE: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9190== by 0x4D2583: ??? (in /usr/local/bin/mplayer)
==9190== by 0x4D2C37: ??? (in /usr/local/bin/mplayer)
==9190== by 0x4B60B4: config_video_out (in /usr/local/bin/mplayer)
==9190== Address 0x7feffe0d4 is on thread 1's stack
==9190==
==9190== Conditional jump or move depends on uninitialised value(s)
==9190== at 0x107AC4D4: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9190== by 0x107AC696: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9190== by 0x107ADA88: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9190== by 0x10957CEE: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9190== by 0x4D2583: ??? (in /usr/local/bin/mplayer)
==9190== by 0x4D2C37: ??? (in /usr/local/bin/mplayer)
==9190== by 0x4B60B4: config_video_out (in /usr/local/bin/mplayer)
==9190== by 0x57DB6B: ??? (in /usr/local/bin/mplayer)
==9190== by 0x546D11: vf_next_config (in /usr/local/bin/mplayer)
==9190== by 0x572D6D: ??? (in /usr/local/bin/mplayer)
==9190== by 0x548114: vf_config_wrapper (in /usr/local/bin/mplayer)
==9190== by 0x544C0E: mpcodecs_config_vo (in /usr/local/bin/mplayer)
==9190==
vex amd64->IR: unhandled instruction bytes: 0xF 0xF 0xC1 0xBF 0xF 0xF 0xCA 0xBF
==9190== valgrind: Unrecognised instruction at address 0xc35202.
==9190== at 0xC35202: ??? (in /usr/local/bin/mplayer)
==9190== by 0xAA3669: ??? (in /usr/local/bin/mplayer)
==9190== by 0xAA5702: ff_MPV_motion (in /usr/local/bin/mplayer)
==9190== by 0xA913A3: ff_MPV_decode_mb (in /usr/local/bin/mplayer)
==9190== by 0x93EDBF: ??? (in /usr/local/bin/mplayer)
==9190== by 0x93FD0B: ff_h263_decode_frame (in /usr/local/bin/mplayer)
==9190== by 0xB7E6FD: avcodec_decode_video2 (in /usr/local/bin/mplayer)
==9190== by 0x631075: ??? (in /usr/local/bin/mplayer)
==9190== by 0x540395: decode_video (in /usr/local/bin/mplayer)
==9190== by 0x4AC2BB: ??? (in /usr/local/bin/mplayer)
==9190== by 0x4A035D: main (in /usr/local/bin/mplayer)
==9190== Your program just tried to execute an instruction that Valgrind
==9190== did not recognise. There are two possible reasons for this.
==9190== 1. Your program has a bug and erroneously jumped to a non-code
==9190== location. If you are running Memcheck and you just saw a
==9190== warning about a bad jump, it's probably your program's fault.
==9190== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9190== i.e. it's Valgrind's fault. If you think this is the case or
==9190== you are not sure, please let us know and we'll try to fix it.
==9190== Either way, Valgrind will now raise a SIGILL signal which will
==9190== probably kill your program.
MPlayer interrupted by signal 4 in module: decode_video
- MPlayer crashed by an 'Illegal Instruction'.
It usually happens when you run it on a CPU different than the one it was
compiled/optimized for.
Verify this!
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.
==9190==
==9190== HEAP SUMMARY:
==9190== in use at exit: 18,275,909 bytes in 4,246 blocks
==9190== total heap usage: 5,464 allocs, 1,218 frees, 22,946,406 bytes allocated
==9190==
==9190== LEAK SUMMARY:
==9190== definitely lost: 1,308 bytes in 4 blocks
==9190== indirectly lost: 0 bytes in 0 blocks
==9190== possibly lost: 0 bytes in 0 blocks
==9190== still reachable: 18,274,601 bytes in 4,242 blocks
==9190== suppressed: 0 bytes in 0 blocks
==9190== Rerun with --leak-check=full to see details of leaked memory
==9190==
==9190== For counts of detected and suppressed errors, rerun with: -v
==9190== Use --track-origins=yes to see where uninitialised values come from
==9190== ERROR SUMMARY: 42 errors from 10 contexts (suppressed: 2 from 2)
This seems to suggest that there is an error in the code of mplayer, in
that it is trying to jump to an undefined pointer. Since the video
plays fine without valgrind, I assume this is spurious, but it means
that I can't get to the real error that is occurring. I don't get a
chance to press q while the video is playing. I can press it while
valgrind processing is going on, but that probably won't be in the same
code, I think.
I then added a few more options that valgrind suggested, and came up
with the command below.
$ valgrind --tool=memcheck --leak-check=full --track-origins=yes mplayer -nosound Walter_Futter_Africa_Speaks_1930.avi
Here is the relevant output.
Starting playback...
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
[swscaler @ 0x1072b40]using unscaled yuv420p -> bgra special converter
VO: [gl] 640x480 => 640x480 BGRA
==9488== Syscall param ioctl(generic) points to uninitialised byte(s)
==9488== at 0x3C046EA2F7: ioctl (in /usr/lib64/libc-2.15.so)
==9488== by 0x3C126035F7: drmIoctl (in /usr/lib64/libdrm.so.2.4.0)
==9488== by 0x10D85140: ??? (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9488== by 0x10D8529B: nouveau_bo_ref (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9488== by 0x10D841AF: ??? (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9488== by 0x10D8464F: nouveau_pushbuf_flush (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9488== by 0x107AC6AB: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x107ADA88: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x10957CEE: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x4D2583: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4D2C37: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4B60B4: config_video_out (in /usr/local/bin/mplayer)
==9488== Address 0x7feffe0d4 is on thread 1's stack
==9488== Uninitialised value was created by a stack allocation
==9488== at 0x10D850F0: ??? (in /usr/lib64/libdrm_nouveau.so.1.0.0)
==9488==
==9488== Conditional jump or move depends on uninitialised value(s)
==9488== at 0x107AC4D4: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x107AC696: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x107ADA88: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x10957CEE: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x4D2583: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4D2C37: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4B60B4: config_video_out (in /usr/local/bin/mplayer)
==9488== by 0x57DB6B: ??? (in /usr/local/bin/mplayer)
==9488== by 0x546D11: vf_next_config (in /usr/local/bin/mplayer)
==9488== by 0x572D6D: ??? (in /usr/local/bin/mplayer)
==9488== by 0x548114: vf_config_wrapper (in /usr/local/bin/mplayer)
==9488== by 0x544C0E: mpcodecs_config_vo (in /usr/local/bin/mplayer)
==9488== Uninitialised value was created by a heap allocation
==9488== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==9488== by 0x107A8CF3: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x107A8ECC: ??? (in /usr/lib64/dri/nouveau_vieux_dri.so)
==9488== by 0x3C1364789E: ??? (in /usr/lib64/libGL.so.1.2)
==9488== by 0x3C1361E876: ??? (in /usr/lib64/libGL.so.1.2)
==9488== by 0x3C1361F003: glXCreateContext (in /usr/lib64/libGL.so.1.2)
==9488== by 0x4CC632: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4D4314: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4B5EF1: init_best_video_out (in /usr/local/bin/mplayer)
==9488== by 0x4AEBD0: reinit_video_chain (in /usr/local/bin/mplayer)
==9488== by 0x49EEDD: main (in /usr/local/bin/mplayer)
==9488==
vex amd64->IR: unhandled instruction bytes: 0xF 0xF 0xC1 0xBF 0xF 0xF 0xCA 0xBF
==9488== valgrind: Unrecognised instruction at address 0xc35202.
==9488== at 0xC35202: ??? (in /usr/local/bin/mplayer)
==9488== by 0xAA3669: ??? (in /usr/local/bin/mplayer)
==9488== by 0xAA5702: ff_MPV_motion (in /usr/local/bin/mplayer)
==9488== by 0xA913A3: ff_MPV_decode_mb (in /usr/local/bin/mplayer)
==9488== by 0x93EDBF: ??? (in /usr/local/bin/mplayer)
==9488== by 0x93FD0B: ff_h263_decode_frame (in /usr/local/bin/mplayer)
==9488== by 0xB7E6FD: avcodec_decode_video2 (in /usr/local/bin/mplayer)
==9488== by 0x631075: ??? (in /usr/local/bin/mplayer)
==9488== by 0x540395: decode_video (in /usr/local/bin/mplayer)
==9488== by 0x4AC2BB: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4A035D: main (in /usr/local/bin/mplayer)
==9488== Your program just tried to execute an instruction that Valgrind
==9488== did not recognise. There are two possible reasons for this.
==9488== 1. Your program has a bug and erroneously jumped to a non-code
==9488== location. If you are running Memcheck and you just saw a
==9488== warning about a bad jump, it's probably your program's fault.
==9488== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9488== i.e. it's Valgrind's fault. If you think this is the case or
==9488== you are not sure, please let us know and we'll try to fix it.
==9488== Either way, Valgrind will now raise a SIGILL signal which will
==9488== probably kill your program.
MPlayer interrupted by signal 4 in module: decode_video
- MPlayer crashed by an 'Illegal Instruction'.
It usually happens when you run it on a CPU different than the one it was
compiled/optimized for.
Verify this!
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.
==9488==
==9488== HEAP SUMMARY:
==9488== in use at exit: 18,275,909 bytes in 4,246 blocks
==9488== total heap usage: 5,464 allocs, 1,218 frees, 22,946,406 bytes allocated
==9488==
==9488== 6 bytes in 1 blocks are definitely lost in loss record 21 of 516
==9488== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==9488== by 0x3C046853D1: strdup (in /usr/lib64/libc-2.15.so)
==9488== by 0x5E128E: get_term_charset (in /usr/local/bin/mplayer)
==9488== by 0x51A75B: mp_msg_init (in /usr/local/bin/mplayer)
==9488== by 0x49D92B: main (in /usr/local/bin/mplayer)
==9488==
==9488== 22 bytes in 1 blocks are definitely lost in loss record 81 of 516
==9488== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==9488== by 0x3C046853D1: strdup (in /usr/lib64/libc-2.15.so)
==9488== by 0x516970: ??? (in /usr/local/bin/mplayer)
==9488== by 0x514E92: m_config_register_options (in /usr/local/bin/mplayer)
==9488== by 0x49D955: main (in /usr/local/bin/mplayer)
==9488==
==9488== 640 bytes in 1 blocks are definitely lost in loss record 340 of 516
==9488== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==9488== by 0x5632B15: XGetVisualInfo (in /usr/lib64/libX11.so.6.3.0)
==9488== by 0x3C1361D82B: glXChooseVisual (in /usr/lib64/libGL.so.1.2)
==9488== by 0x4D0841: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4D4305: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4B5EF1: init_best_video_out (in /usr/local/bin/mplayer)
==9488== by 0x4AEBD0: reinit_video_chain (in /usr/local/bin/mplayer)
==9488== by 0x49EEDD: main (in /usr/local/bin/mplayer)
==9488==
==9488== 640 bytes in 1 blocks are definitely lost in loss record 341 of 516
==9488== at 0x4A0884D: malloc (vg_replace_malloc.c:263)
==9488== by 0x5632B15: XGetVisualInfo (in /usr/lib64/libX11.so.6.3.0)
==9488== by 0x3C1361D82B: glXChooseVisual (in /usr/lib64/libGL.so.1.2)
==9488== by 0x4D0841: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4D2BF9: ??? (in /usr/local/bin/mplayer)
==9488== by 0x4B60B4: config_video_out (in /usr/local/bin/mplayer)
==9488== by 0x57DB6B: ??? (in /usr/local/bin/mplayer)
==9488== by 0x546D11: vf_next_config (in /usr/local/bin/mplayer)
==9488== by 0x572D6D: ??? (in /usr/local/bin/mplayer)
==9488== by 0x548114: vf_config_wrapper (in /usr/local/bin/mplayer)
==9488== by 0x544C0E: mpcodecs_config_vo (in /usr/local/bin/mplayer)
==9488== by 0x630D9A: ??? (in /usr/local/bin/mplayer)
==9488==
==9488== LEAK SUMMARY:
==9488== definitely lost: 1,308 bytes in 4 blocks
==9488== indirectly lost: 0 bytes in 0 blocks
==9488== possibly lost: 0 bytes in 0 blocks
==9488== still reachable: 18,274,601 bytes in 4,242 blocks
==9488== suppressed: 0 bytes in 0 blocks
==9488== Reachable blocks (those to which a pointer was found) are not shown.
==9488== To see them, rerun with: --leak-check=full --show-reachable=yes
==9488==
==9488== For counts of detected and suppressed errors, rerun with: -v
==9488== ERROR SUMMARY: 46 errors from 14 contexts (suppressed: 2 from 2)
This implies that there are memory leaks, and gives the chain of their
occurrence, as near as I can tell. But I don't know what it means, and
whether they too are false warnings. Or is it pointing to the malloc
calls in their libraries?
Thanks for any insight you can offer. Should this be run on the debug
version of mplayer instead? I haven't yet created that, thought I'd
have a look as valgrind first.
If this is a waste of your time, let me know and I'll stop. Mplayer
seems to work for my needs, if not flawlessly, so I can live with the
flaws.
More information about the MPlayer-users
mailing list