mplayer-1.5 crashes with SIG11 playing an mp4 audio file. ffplay is able to play the same file, as is mplayer-1.5 on other local computers. Reproducible: Always Steps to Reproduce: 1.emerge @world Dec. 26 2.mplayer /tmp/sample.mp4 3. Actual Results: mplayer reports SIG11 "in demux_open()" however gdb-->bt indicates the violation happens deep in libavcodec, in decode_cpe (src/libavcodec/aacdec_template.c:2300) backtrace attached. Expected Results: mplayer was playing these files just fine previously. In the so-weird-I-don't-know-what-to-make-of-it department, mplayer-1.5 also crashes on various video mp4 files but is able to play them just fine when they are symlinked into /tmp ! The crash is at the same line of aacdec_template.c, but the backtrace is very different. ffplay is also able to play these files just fine from their unsymlinked locations.
Created attachment 845541 [details] emerge-info.txt
Created attachment 845543 [details] mplayer-info.txt
Created attachment 845545 [details] ffmpeg-info.txt
Created attachment 845547 [details] mplayer build log
Created attachment 845549 [details] ffmpeg build log
Created attachment 845551 [details] backtrace of reported SIG11 Backtrace of the crash reported in the bug report, through demux_open()
Created attachment 845553 [details] Backtrace of additional SIG11 caught as mentioned in "additional information" This is the backtrace occuring when a video file that plays fine when copied to /tmp crashes when played from its original location. This crash is through dec_audio().
Update: Upgrade to kernel 6.1.6 does not affect this bug. Copying files that cause segmentation faults sometimes results in a file being playable despite having the same cksum. As an erstwhile filesystem software programmer this makes me extremely curious as to what is actually going on.
I'm also experiencing this same exact issue
The symlink/not symlink element of this is pretty concerning. Obviously it sounds like it might be an ffmpeg bug otherwise. It's tricky as well because we can't yet unmask >=ffmpeg-5 because so much software (including the venerable VLC) doesn't work with it yet - bug 831437. I don't think I'm able to offer much guidance at the moment. It sounds like it's worth possibly reporting to the mplayer people first, then see if they think it's worth either sending to ffmpeg, or whether to the kernel people, with hopefully some ideas on how to debug further.
Sorry, I should've been more explicit: please try ffmpeg 5.1.x in Gentoo first. Upstream partly maintain older branches but they (I'm told by an ffmpeg person) only cherry pick stuff which folks both remember + apply cleanly, so 4.4.x is possibly missing a relevant fix.
(In reply to Sam James from comment #11) > Sorry, I should've been more explicit: please try ffmpeg 5.1.x in Gentoo > first. Upstream partly maintain older branches but they (I'm told by an > ffmpeg person) only cherry pick stuff which folks both remember + apply > cleanly, so 4.4.x is possibly missing a relevant fix. I can confirm that compiling ffmpeg 5.1.2-r1 fixes this issue inasmuch as ffplay now plays everything I throw at it. However, mplayer refuses to build with ffmpeg 5.1.2-r1 :P It looks like missing or significantly incompatible ffmpeg headers to me. Let me know if there's a way to get mplayer to build and I'll test it too.
Created attachment 850010 [details] failed mplayer build log Failed build log from mplayer trying to build with ffmpeg-5.1.2-r1
(In reply to Whilom Chime from comment #12) > (In reply to Sam James from comment #11) > > Sorry, I should've been more explicit: please try ffmpeg 5.1.x in Gentoo > > first. Upstream partly maintain older branches but they (I'm told by an > > ffmpeg person) only cherry pick stuff which folks both remember + apply > > cleanly, so 4.4.x is possibly missing a relevant fix. > > I can confirm that compiling ffmpeg 5.1.2-r1 fixes this issue inasmuch as > ffplay now plays everything I throw at it. However, mplayer refuses to > build with ffmpeg 5.1.2-r1 :P I'm both very pleased it works and also was hoping you wouldn't say that, as it means we have another reason to push onto ffmpeg >= 5.x :| > It looks like missing or significantly > incompatible ffmpeg headers to me. Let me know if there's a way to get > mplayer to build and I'll test it too. Could you try mplayer-9999 and let me know if that works? If it does, we can try figure out which patches to backport (help welcome on that). Arch is currently using a snapshot from SVN (https://github.com/archlinux/svntogit-packages/commit/8b093a62073f2a4674a49d2c6b708d1b53e0b18f) to get ffmpeg 5 support so maybe we should do the same...
(In reply to Sam James from comment #14) > > Could you try mplayer-9999 and let me know if that works? If it does, we can > try figure out which patches to backport (help welcome on that). > > Arch is currently using a snapshot from SVN > (https://github.com/archlinux/svntogit-packages/commit/ > 8b093a62073f2a4674a49d2c6b708d1b53e0b18f) to get ffmpeg 5 support so maybe > we should do the same... mplayer-9999 compiles just fine with ffmpeg-5.2.1-r1, but the same file that used to crash ffplay and doesn't crash ffplay-5.2.1-r1 does still crash mplayer SIG11 in demux_open() same API as before, though I haven't looked at the stack trace. Assuming demux_open() is in libavcodec I've confirmed libavcodec got recompiled; it's showing up with todays date in /usr/lib64 as libavcodec.so.59.37.100. I'd be happy to help with the patch hunt if we get to that.
I'm sort of out of ideas other than reporting it to the ffmpeg people at this point. But I'll add a snapshot of new mplayer at least.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=182bb7a92d0e6fc1f0bc32546d53d12f40d86215 commit 182bb7a92d0e6fc1f0bc32546d53d12f40d86215 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-15 07:25:19 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-15 07:25:59 +0000 media-video/mplayer: add 1.5_p20230215 (snapshot for >=ffmpeg-5, unkw'd for now) Unkeyworded until had some more testing (please let us know in a comment on one of the linked bugs if it works/doesn't). Bug: https://bugs.gentoo.org/876760 Bug: https://bugs.gentoo.org/888821 Signed-off-by: Sam James <sam@gentoo.org> media-video/mplayer/Manifest | 1 + media-video/mplayer/files/prepare_mplayer.sh | 42 +- media-video/mplayer/mplayer-1.5_p20230215.ebuild | 631 +++++++++++++++++++++++ media-video/mplayer/mplayer-9999.ebuild | 10 +- 4 files changed, 665 insertions(+), 19 deletions(-)
(In reply to Sam James from comment #16) > I'm sort of out of ideas other than reporting it to the ffmpeg people at > this point. > > But I'll add a snapshot of new mplayer at least. Thanks. I have some days off coming up, I will try to find the time to GDB through the crash and see if I can make sense of what might be going on. If I find anything interesting I'll report back.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=86b79f2f09384512b5467ab67804716ec8a1e30e commit 86b79f2f09384512b5467ab67804716ec8a1e30e Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-18 19:57:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-06-18 21:04:49 +0000 media-video/mplayer: add 1.5_p20230618 Bug: https://bugs.gentoo.org/888821 Bug: https://bugs.gentoo.org/908553 Signed-off-by: Sam James <sam@gentoo.org> media-video/mplayer/Manifest | 1 + media-video/mplayer/mplayer-1.5_p20230618.ebuild | 641 +++++++++++++++++++++++ media-video/mplayer/mplayer-9999.ebuild | 7 +- 3 files changed, 646 insertions(+), 3 deletions(-)
