mplayer carashes on flv and mp4 video. > mplayer Dopesmoker.flv MPlayer SVN-r36558-snapshot-3.2 (C) 2000-2013 MPlayer Team Playing Dopesmoker.flv. libavformat version 55.22.100 (internal) libavformat file format detected. MPlayer interrupted by signal 10 in module: demux_open - 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. > mplayer hamburg.mp4 MPlayer SVN-r36558-snapshot-3.2 (C) 2000-2013 MPlayer Team Playing hamburg.mp4. libavformat version 55.22.100 (internal) libavformat file format detected. MPlayer interrupted by signal 10 in module: demux_open - 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. How-To-Repeat: play any mp4 or flv video.
State Changed From-To: open->feedback Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Maintainer of multimedia/mplayer, Please note that PR ports/185560 has just been submitted. If it contains a patch for an upgrade, an enhancement or a bug fix you agree on, reply to this email stating that you approve the patch and a committer will take care of it. The full text of the PR can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185560 -- Edwin Groothuis via the GNATS Auto Assign Tool edwin@FreeBSD.org
I can't reproduce this. mplayer does literally play every single mp4 and flv video that I have. No crashes. Is this really an almost one year old system you are running this on? Could you try an up-to-date 9.2 stable with up-to-date ports? Thanks Riggs
I still can't reproduce this problem. Also there has not been any other user mentioning this kind of problem. Likely cause are local issues on submitter's machine. Propose to close this PR. Regards Riggs
Responsible Changed From-To: freebsd-ports-bugs->riggs I'll take it.
State Changed From-To: feedback->closed Not reproducible, no response from submitter.
Unfortunately I have the same issue on FreeBSD 10.0-STABLE i386 (r266795). The CPU in this (cr**) machine is: CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz (2277.66-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Family = 0xf Model = 0x2 Stepping = 4 Features=0x3febfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM % mplayer bsd-0041.mp4 MPlayer SVN-r37153-snapshot-4.2.1 (C) 2000-2014 MPlayer Team Playing bsd-0041.mp4. libavformat version 55.37.100 (internal) libavformat file format detected. MPlayer interrupted by signal 10 in module: demux_open - 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. I found two ways to make mplayer work on my system: 1) Build mplayer in a gcc based jail (WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes WITH_GCC=yes WITH_GNUCXX=yes) with gcc 4.2 from base 2) With clang setting OCFLAGS=off and build mplayer # cd /usr/ports/multimedia/mplayer # env CFLAGS="" make install (I am not setting CFLAGS anywhere)
I can reproduce the problem fine with some MP4 files downloaded from Youtube, for example with this: $ youtube-dl 'https://www.youtube.com/watch?v=-jOHHyJMgWk' $ mplayer 'Acer C720 Chromebook SSD Upgrade MyDigitalSSD 128GB--jOHHyJMgWk.mp4' The system in question is HEAD r269739 with ports r364424; the CPU is: $ dmesg | fgrep -i cpu CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs The same problem occurs in HEAD r269739 with ports from October, 18 and in a VM with CPUs: $ dmesg | fgrep -i cpu CPU: Intel(R) Core(TM) i5-3360M CPU @ 2.80GHz (2791.11-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Please re-open the PR again as we now have a reproduceable case. Thanks
I have switched off optimization for clang with: # diff Makefile.options Makefile.options.orig 155c155 < CFLAGS+= -O0 --- > CFLAGS+= -O -fomit-frame-pointer and the resulting mplayer plays fine; (note: -O nearly to -O2 for clang)
I can't reproduce this problem with the video you mentioned, but if you can, this should help us. Re-opening this PR to track further actions.
(In reply to Matthias Apitz from comment #9) > I have switched off optimization for clang with: > > # diff Makefile.options Makefile.options.orig > 155c155 > < CFLAGS+= -O0 > --- > > CFLAGS+= -O -fomit-frame-pointer > > and the resulting mplayer plays fine; > > (note: -O nearly to -O2 for clang) What happens if you use -O0 -fomit-frame-pointer ?
(In reply to Thomas Zander from comment #11) > (In reply to Matthias Apitz from comment #9) > > I have switched off optimization for clang with: > > > > # diff Makefile.options Makefile.options.orig > > 155c155 > > < CFLAGS+= -O0 > > --- > > > CFLAGS+= -O -fomit-frame-pointer > > > > and the resulting mplayer plays fine; > > > > (note: -O nearly to -O2 for clang) > > What happens if you use -O0 -fomit-frame-pointer ? It crashes compiled with CFLAGS+= -O0 -fomit-frame-pointer it does no crash with CFLAGS+= -O0 or CFLAGS+= -O3 all tests done with the same (mentioned) MP4 file; btw: the CFLAGS from Makefile.option only work when one runs setenv CFLAGS '' make
(In reply to Matthias Apitz from comment #12) > it does no crash with > > CFLAGS+= -O0 > or > CFLAGS+= -O3 > > all tests done with the same (mentioned) MP4 file; Interesting. Your CPU seems to require that frame pointer to be stored. In the past, we had build failures without -fomit-frame-pointer when the compiler ran out of registers. I'll look into that. > btw: the CFLAGS from Makefile.option only work when one runs > > setenv CFLAGS '' > make Are you saying the CFLAGS from the port Makefile are ignored unless you empty the variable prior to build? Are you enforcing CFLAGS=someFlags in make.conf? If so, please switch to using CFLAGS+=....
(In reply to Thomas Zander from comment #13) > (In reply to Matthias Apitz from comment #12) > > > btw: the CFLAGS from Makefile.option only work when one runs > > > > setenv CFLAGS '' > > make > > Are you saying the CFLAGS from the port Makefile are ignored unless you > empty the variable prior to build? Are you enforcing CFLAGS=someFlags in > make.conf? If so, please switch to using CFLAGS+=.... I do not have any CFLAGS in /etc/make.conf; if I do unsetenv CFLAGS make it compiles with clang -MMD -MP -D_ISOC99_SOURCE -I. -Iffmpeg -O2 -pipe -DLIBICONV_PLUG -O3 -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FILE_OFFSET_BITS=64 .... the -O3 comes from Makefile.options, but there is some -O2 before; don't know where this comes from;
(In reply to Matthias Apitz from comment #14) > the -O3 comes from Makefile.options, but there is some -O2 before; don't > know where this comes from; That's the system default, nothing to worry about: [riggs] ~ > cd /tmp [riggs] /tmp > make -V CFLAGS -O2 -pipe
Since signal 10 is SIGBUS, I really expect this to be yet another stack alignment problem, just as with the ffmpeg ports. E.g., like ffmpeg, mplayer probably assumes a 16 byte stack alignment throughout, even on i386, since that is how the stack is aligned on i386-linux. However, it is 4 byte aligned on i386-freebsd. Can anyone please provide a backtrace and register dump from a crashing mplayer instance?
(In reply to Dimitry Andric from comment #16) > Since signal 10 is SIGBUS, I really expect this to be yet another stack > alignment problem, just as with the ffmpeg ports. E.g., like ffmpeg, > mplayer probably assumes a 16 byte stack alignment throughout, even on i386, > since that is how the stack is aligned on i386-linux. However, it is 4 byte > aligned on i386-freebsd. > > Can anyone please provide a backtrace and register dump from a crashing > mplayer instance? The compiler in question is clang and I tried to compile with debug information, with the flags: clang ... -g -O0 -fomit-frame-pointer -ffast-math ... but the resulting bt is unuseable: Program received signal SIGBUS, Bus error. 0x01f14182 in ?? () (gdb) bt #0 0x01f14182 in ?? () #1 0x0112ff08 in ?? () #2 0xa1000000 in ?? () #3 0x0113ff08 in ?? () #4 0x96000000 in ?? () #5 0x0114ff08 in ?? () #6 0x97000000 in ?? () ... #65 0x240d9e60 in ?? () #66 0x00000520 in ?? () #67 0x00000004 in ?? () #68 0x00000002 in ?? () ---Type <return> to continue, or q <return> to quit--- #69 0x00000000 in ?? () (gdb) If someone has an idea how to get mor information, please let me know.
As Konstantin has suggested in the mail thread on multimedia, could you add -mstackrealign to the compiler flags and check if this fixes the crashing?
(In reply to Thomas Zander from comment #18) > As Konstantin has suggested in the mail thread on multimedia, could you add > -mstackrealign to the compiler flags and check if this fixes the crashing? Probably "-mstack-alignment=16 -mstackrealign" for Clang on i386 like multimedia/gstreamer1-libav does.
Gdb can't seem to cope with mplayer, especially not if it is compiled with the default flags. I tried lldb, and it fared a bit better, though it still can't figure out the stack, obviously because there are no frame pointers: (lldb) target create "/usr/local/bin/mplayer" Current executable set to '/usr/local/bin/mplayer' (i386). (lldb) settings set -- target.run-args "20120823_142518.mp4" (lldb) run Process 2385 launching Process 2385 stopped Process 2385 launched: '/usr/local/bin/mplayer' (i386) MPlayer SVN-r37257-snapshot-3.5.0 (C) 2000-2014 MPlayer Team Playing 20120823_142518.mp4. libavformat version 56.2.100 (internal) libavformat file format detected. Process 2385 stopped * thread #1: tid = 100600, 0x01a17022 mplayer, name = 'mplayer', stop reason = hardware error frame #0: 0x01a17022 mplayer -> 0x1a17022: vmovdqa (%esi,%ecx), %xmm0 0x1a17027: vmovdqa (%esi,%ecx,2), %xmm1 0x1a1702c: vmovdqa (%eax), %xmm2 0x1a17030: vmovdqa (%eax,%ecx), %xmm3 (lldb) register read General Purpose Registers: eax = 0xbfbfcb18 ebx = 0x00000002 ecx = 0x00000010 edx = 0x00000006 edi = 0x23170020 esi = 0xbfbfcae8 ebp = 0xbfbfcc1c esp = 0xbfbfca98 eip = 0x01a17022 eflags = 0x00010287 cs = 0x00000033 fs = 0x0000003b gs = 0x0000001b ss = 0x0000003b ds = 0x0000003b es = 0x0000003b E.g. you can clearly see that is trying to move data which is not 16-byte aligned to xmm0: %esi is 0xbfbfcae8 and %ecx is 0x00000010. I'm not sure where these instructions come from, but I would bet they are from assembly source compiled with yasm, with the assumption of an incoming stack alignment of 16 bytes.
compiled with: clang -MMD -MP -D_ISOC99_SOURCE -I. -Iffmpeg -DLIBICONV_PLUG -O3 -mstackrealign -fomit-frame-pointer -ffast-math -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FILE_OFFSET_BITS=64 -Ilibdvdread4 -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/gtk-2.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -D_THREAD_SAFE -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng15 -I/usr/local/include/pango-1.0 -pthread -I/usr/local/include/glib-2.0 -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/harfbuzz -c -o ... gives: audio, but black picture; messages in terminal: ... X11 error: BadAlloc (insufficient resources for operation) A: 11.1 V: 9.3 A-V: 1.750 ct: 0.040 0/ 0 95% 9% 4.1% 162 0 X11 error: BadAlloc (insufficient resources for operation) A: 11.1 V: 9.4 A-V: 1.742 ct: 0.040 0/ 0 95% 9% 4.1% 163 0 X11 error: BadAlloc (insufficient resources for operation) A: 11.2 V: 9.4 A-V: 1.766 ct: 0.040 0/ 0 95% 9% 4.1% 164 0 X11 error: BadAlloc (insufficient resources for operation) ... and all new started X clients (xterm, urxvt, ...) have black foreground; compiled with: clang -MMD -MP -D_ISOC99_SOURCE -I. -Iffmpeg -DLIBICONV_PLUG -O3 -mstack-alignment=16 -mstackrealign -fomit-frame-pointer -ffast-math -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FILE_OFFSET_BITS=64 -Ilibdvdread4 -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/gtk-2.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -D_THREAD_SAFE -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng15 -I/usr/local/include/pango-1.0 -pthread -I/usr/local/include/glib-2.0 -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/harfbuzz -Wno-strict-prototypes -c -o gives: plays video and audio fine;
(In reply to Dimitry Andric from comment #20) > * thread #1: tid = 100600, 0x01a17022 mplayer, name = 'mplayer', stop reason > = hardware error > frame #0: 0x01a17022 mplayer > -> 0x1a17022: vmovdqa (%esi,%ecx), %xmm0 > 0x1a17027: vmovdqa (%esi,%ecx,2), %xmm1 > [...] > E.g. you can clearly see that is trying to move data which is not 16-byte > aligned to xmm0: %esi is 0xbfbfcae8 and %ecx is 0x00000010. > > I'm not sure where these instructions come from, but I would bet they are > from assembly source compiled with yasm, with the assumption of an incoming > stack alignment of 16 bytes. These two vmovdqa come from ffmpeg/libavfilter/x86/af_volume.asm:88,89, so you are right. This is compiled with yasm.
(In reply to Matthias Apitz from comment #21) > compiled with: > > clang -MMD -MP -D_ISOC99_SOURCE -I. -Iffmpeg -DLIBICONV_PLUG -O3 > -mstack-alignment=16 -mstackrealign -fomit-frame-pointer -ffast-math > -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_FILE_OFFSET_BITS=64 -Ilibdvdread4 -I/usr/local/include > -I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include > -I/usr/local/include/freetype2 -I/usr/local/include/gtk-2.0 > -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/atk-1.0 > -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -D_THREAD_SAFE > -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng15 > -I/usr/local/include/pango-1.0 -pthread -I/usr/local/include/glib-2.0 > -I/usr/local/include -I/usr/local/include/freetype2 > -I/usr/local/include/harfbuzz -Wno-strict-prototypes -c -o > > gives: > > plays video and audio fine; Thanks! Seems we are getting there! I'll prepare an updated tarball for the new mplayer for testing. Will announce it on the mailing list shortly.
Fixed in r375775 by introducing -mstack-alignment=16 -mstackrealign on clang/i386
I've faced this issue couple months ago. The solution was to switch to mplayer2. However, today mplayer2 started crashing too. I am trying switch back to mplayer. I've updated my ports tree and re-installed mplayer with all the dependencies. Now it crashes on mp4 files (avi works ok). As an example - this video: https://www.youtube.com/watch?v=XF8GdV4H5gc ( http://r1---sn-5hn7su76.googlevideo.com/videoplayback?expire=1430594141&pl=23&id=o-AEZHWGzsmu_W6HipvcwTnlg9aSpycQquoYQ473xhxB63&dur=107.810&signature=5A798476227CBA4ACB09EB30E8EBC69E70E69708.5FE273E1AEC74570D3391638B5A002AD8452E98B&ipbits=0&key=cms1&source=youtube&sparams=dur,expire,id,ip,ipbits,itag,mime,mm,mn,ms,mv,pl,ratebypass,source,upn&itag=18&ratebypass=yes&upn=vKFqbCc0iG8&ip=85.17.226.244&mime=video%2Fmp4&fexp=900720%2C907263%2C934954%2C938028%2C9405967%2C9408139%2C9408142%2C9408623%2C9408706%2C9409097%2C9409252%2C9412836%2C948124%2C952612%2C952637%2C952642%2C957201&sver=3&title=ASUS%20demo&req_id=30e69d4f66b6a3ee&redirect_counter=2&cms_redirect=yes&mm=26&mn=sn-5hn7su76&ms=tsu&mt=1430572273&mv=u ) When playing, I am receiving this: % mplayer ASUS\ demo.mp4 MPlayer SVN-r37386-snapshot-3.4.1 (C) 2000-2015 MPlayer Team Playing ASUS demo.mp4. libavformat version 56.28.100 (internal) libavformat file format detected. MPlayer interrupted by signal 10 in module: demux_open - 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. % uname -m i386 What additional information should I provide in order to identify this issue?
My CPU and system are: % dmesg | grep CPU: CPU: Intel(R) Core(TM)2 Duo CPU T5250 @ 1.50GHz (1496.68-MHz 686-class CPU) % uname -a FreeBSD chisel 10.1-RELEASE FreeBSD 10.1-RELEASE #0: Sun Nov 23 11:07:18 MSK 2014 root@chisel:/usr/obj/usr/src/sys/CHISEL i386