Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 915384 - media-video/ffmpeg-4.4.4-r4: Crash when decoding AAC files with unset CPU_FLAGS_X86
Summary: media-video/ffmpeg-4.4.4-r4: Crash when decoding AAC files with unset CPU_FLA...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal critical
Assignee: Gentoo Media-video project
URL:
Whiteboard:
Keywords:
: 918964 (view as bug list)
Depends on: 926151
Blocks: gcc-13
  Show dependency tree
 
Reported: 2023-10-08 14:27 UTC by realmariomario456
Modified: 2025-03-11 09:03 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---

Attachments
Backtrace (backtrace.log%0A,9.28 KB, text/plain)
2023-10-08 14:27 UTC, realmariomario456 		Details
emerge --info (debug make.conf) (emerge-info-debug.txt,6.93 KB, text/plain)
2023-10-08 14:27 UTC, realmariomario456 		Details
emerge --info (standard make.conf) (emerge-info.txt,6.89 KB, text/plain)
2023-10-08 14:28 UTC, realmariomario456 		Details
strace (strace.log,159.79 KB, text/x-log)
2023-10-08 14:28 UTC, realmariomario456 		Details
emerge -pv and emege --info for ffmpeg (ffmpeg_emerge_pv_info.txt,10.69 KB, text/plain)
2023-12-22 13:59 UTC, publiccontact2020 		Details
emerge --info ffmpeg (emerge --info ffmpeg.txt,8.47 KB, text/plain)
2024-10-20 21:10 UTC, Albert 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description realmariomario456 2023-10-08 14:27:19 UTC 
Created attachment 872336 [details]
Backtrace

This wasn't happening to me before, but now when FFmpeg tries to decode AAC (always with the FFmpeg command-line tool, most of the time with Audacity) it results in a crash. I've attached a full backtrace, strace and two emerge --infos (one is for my debugging make.conf, the other is for my standard make.conf) in this bug report. I assure this bug happens with both of my make.confs.
Comment 1 realmariomario456 2023-10-08 14:27:45 UTC 
Created attachment 872337 [details]
emerge --info (debug make.conf)
Comment 2 realmariomario456 2023-10-08 14:28:08 UTC 
Created attachment 872338 [details]
emerge --info (standard make.conf)
Comment 3 realmariomario456 2023-10-08 14:28:29 UTC 
Created attachment 872339 [details]
strace
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-10-09 00:55:44 UTC 
Thanks.

We've seen this come up a few times recently.

My guess is the reason it's happening (more) now is gcc 13 being recently stabled.

It seems to be related to a mismatch between CPU_FLAGS_X86 and CFLAGS -march. Someone gave us Valgrind output before and it looked fairly clearly like an alignment problem.

For a workaround: please set CPU_FLAGS_X86 per app-portage/cpuid2cpuflags output.
Comment 5 Paul Zander 2023-10-09 08:37:53 UTC 
From your emerge --info:
> CPU_FLAGS_X86="mmx mmxext sse sse2"
So that's the immediate cause.
Comment 6 realmariomario456 2023-10-25 20:09:08 UTC 
(In reply to Sam James from comment #4)
> Thanks.
> 
> We've seen this come up a few times recently.
> 
> My guess is the reason it's happening (more) now is gcc 13 being recently
> stabled.
> 
> It seems to be related to a mismatch between CPU_FLAGS_X86 and CFLAGS
> -march. Someone gave us Valgrind output before and it looked fairly clearly
> like an alignment problem.
> 
> For a workaround: please set CPU_FLAGS_X86 per app-portage/cpuid2cpuflags
> output.

(In reply to Paul Zander from comment #5)
> From your emerge --info:
> > CPU_FLAGS_X86="mmx mmxext sse sse2"
> So that's the immediate cause.

Sorry for the late reply, I wasn't bothered to se CPU_FLAGS_X86 until now. But I've set it and the crash went away. This seems to prove that the crash is ebuild or GCC 13-related.
Comment 7 Matthias Hanft 2023-10-29 16:48:45 UTC 
Can confirm a) the error and b) the workaround.

With gcc 12, everything runs fine - just like that.

With gcc 13 and just the usual

CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
CHOST="x86_64-pc-linux-gnu"

I get

Oct 29 11:16:08 home01 kernel: traps: minidlnad[11961] general protection fault ip:7f44fcc1e2ea sp:7f44fbf48e20 error:0 in 
libavcodec.so.60.3.100[7f44fcbb2000+73b000]

and

Oct 29 17:02:12 home01 kernel: traps: ffmpeg[25236] general protection fault ip:7f349ddb12ea sp:7fff1726b400 error:0 in libavcodec.so.60.3.100[7f349dd45000+73b000]

With gcc 13 and additional

CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3"

(the output of cpuid2cpuflags), everything runs fine with gcc 13, too.

Here are the cpu_flags differences (equery u ffmpeg):

 U I
 - - cpu_flags_x86_3dnow    : Use the 3DNow! instruction set
 - - cpu_flags_x86_3dnowext : Use the Enhanced 3DNow! instruction set
 + - cpu_flags_x86_aes      : Enable support for Intel's AES instruction set (AES-NI)
 + - cpu_flags_x86_avx      : Adds support for Advanced Vector Extensions instructions
 + - cpu_flags_x86_avx2     : Adds support for Advanced Vector Extensions 2 instructions
 + - cpu_flags_x86_fma3     : Use the Fused Multiply Add 3 instruction set ([fma] in cpuinfo)
 - - cpu_flags_x86_fma4     : Use the Fused Multiply Add 4 instruction set
 + + cpu_flags_x86_mmx      : Use the MMX instruction set
 + + cpu_flags_x86_mmxext   : Use the Extended MMX instruction set (a subset of SSE) ([mmxext] or
                              [sse] in cpuinfo)
 + + cpu_flags_x86_sse      : Use the SSE instruction set
 + + cpu_flags_x86_sse2     : Use the SSE2 instruction set
 + - cpu_flags_x86_sse3     : Use the SSE3 instruction set ([pni] in cpuinfo, NOT ssse3)
 + - cpu_flags_x86_sse4_1   : Enable SSE4.1 instruction support
 + - cpu_flags_x86_sse4_2   : Enable SSE4.2 instruction support
 + - cpu_flags_x86_ssse3    : Use the SSSE3 instruction set (NOT sse3/pni)
 - - cpu_flags_x86_xop      : Enable the XOP instruction set

(column "I" is the standard installation without CPU_FLAGS_X86)

Thank you for the workaround, now I can delete gcc 12.
Comment 9 Paul Zander 2023-12-18 12:03:29 UTC 
*** Bug 918964 has been marked as a duplicate of this bug. ***
Comment 10 publiccontact2020 2023-12-19 15:59:56 UTC Comment hidden (obsolete)
Comment 11 Paul Zander 2023-12-19 21:14:50 UTC Comment hidden (obsolete)
Comment 12 publiccontact2020 2023-12-20 16:58:49 UTC Comment hidden (obsolete)
Comment 13 Paul Zander 2023-12-21 15:10:32 UTC 
Follow https://wiki.gentoo.org/wiki/CPU_FLAGS_*#Invocation.

Putting `CPU_FLAGS_X86=` in make.conf is the old method that still works but often leads to confusion.

Otherwise join #gentoo on irc and get help there.
Comment 14 publiccontact2020 2023-12-21 17:28:45 UTC Comment hidden (obsolete)
Comment 15 Paul Zander 2023-12-21 18:22:47 UTC Comment hidden (obsolete)
Comment 16 publiccontact2020 2023-12-22 13:59:16 UTC Comment hidden (obsolete)
Comment 17 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-12-22 14:31:57 UTC Comment hidden (obsolete)
Comment 18 Larry the Git Cow gentoo-dev 2024-02-29 05:44:48 UTC 
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4e4da320675b49841b4e7f477a6efe3c0413f674

commit 4e4da320675b49841b4e7f477a6efe3c0413f674
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2024-02-29 05:42:04 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2024-02-29 05:44:22 +0000

    media-video/ffmpeg: fix crash when CPU_FLAGS_x86 and CFLAGS disagree
    
    When CPU_FLAGS_X86 was set to the default for amd64 and CFLAGS was higher
    with e.g. -march=native including AVX, we could get crashes because we disable
    intrinsics which would otherwise adjust the alignment ffmpeg requests.
    
    Backport an upstream patch for more sensible behaviour.
    
    Note that the upstream patch doesn't apply to 4.4.x but I haven't tried
    to backport it manually. Someone is welcome to, but 4.4.x should really be
    on its way out by now.
    
    Bug: https://trac.ffmpeg.org/ticket/10549
    Bug: https://bugs.gentoo.org/915384
    Signed-off-by: Sam James <sam@gentoo.org>

 media-video/ffmpeg/ffmpeg-6.0.1-r3.ebuild          | 607 ++++++++++++++++++++
 media-video/ffmpeg/ffmpeg-6.1.1-r4.ebuild          | 614 +++++++++++++++++++++
 .../ffmpeg/files/ffmpeg-6.0.1-alignment.patch      | 114 ++++
 3 files changed, 1335 insertions(+)
Comment 19 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-02-29 05:45:09 UTC 
I'll leave this open for a little bit for visibility and in case anyone wants to do the 4.4.x backport.
Comment 20 Albert 2024-10-20 21:10:19 UTC 
Created attachment 906471 [details]
emerge --info ffmpeg
Comment 21 Albert 2024-10-20 21:21:40 UTC 
I am getting very similar issue with ffmpeg 6.1.2 compiled with GCC-14.2.1
CPU_FLAGS_X86 are set correctly as I understand

Failed command:
ffmpeg -hide_banner -hwaccel auto -loglevel error -i demo.mp4 -pix_fmt rgb24 temp/demo/%04d.png
Segmentation fault (core dumped)

Output of cpuid2cpuflags:
CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3

emerge --info ffmpeg:
https://bugs.gentoo.org/attachment.cgi?id=906471

dmesg:
[  730.867908] av:h264:df1[32931]: segfault at 0 ip 00007f6def75883e sp 00007f6dc7ffd750 error 4 in libavcodec.so.60.31.102[68b83e,7f6def0db000+804000] likely on CPU 5 (core 5, socket 0)
[  730.867918] Code: 41 5d 41 5e c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 55 48 89 e5 41 57 49 89 d7 41 56 41 55 4d 89 c5 41 54 49 89 f4 53 48 83 ec 28 <48> 8b 1a 48 89 7c 24 08 48 89 4c 24 18 48 83 3b 00 0f 84 33 04 00
Comment 22 Albert 2024-10-20 21:22:21 UTC Comment hidden (obsolete)
Comment 23 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-10-21 09:27:14 UTC 
Can you file a separate bug please? I suspect it might be different.
Comment 24 Larry the Git Cow gentoo-dev 2025-03-11 09:03:48 UTC 
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=00eddc65d7bd9ecaa9973fd46e544bbbfe5c9479

commit 00eddc65d7bd9ecaa9973fd46e544bbbfe5c9479
Author:     Ionen Wolkens <ionen@gentoo.org>
AuthorDate: 2025-03-07 13:02:23 +0000
Commit:     Ionen Wolkens <ionen@gentoo.org>
CommitDate: 2025-03-11 09:03:17 +0000

    media-video/ffmpeg: rewrite live ebuild
    
    This does not list all changes compared to original due to being
    essentially a rewrite (not much sense in looking at the diff
    given almost no lines in common), but to list or explain notable
    ones:
    
    * Cleanup a lot of obsolete logic, like mirror://gentoo snapshots,
      SCM type, <openssl-3 handling, etc...
    
    * Re-arrange IUSE=soc handling to drop the IUSE when FFMPEG_SOC_PATCH
      is empty until maintainer of the patch has time to look at that
      (easier to bump without it and removes the need to mask in 9999)
    
    * Drop some IUSE, ffmpeg has a bit too many often confusing users and,
      while debatable, some are not really useful to control bare at most
      for expert user that could use EXTRA_ECONF if *really* wanted:
    
      - debug (disabled): does very little beside override users' -g*,
        albeit if want nasm debug symbols will need to set X86ASMFLAGS.
    
      - encode (enabled): debated keeping it for disabling encoders
        without their own USE for bit of size/build time reduction despite
        no dependencies, but feel it is not really worth it as it
        complicates the ebuild and can break expectations for a lot
        of revdeps (many likely lack the [encode] that they need) --
        removal also handles bug #770439
    
      - fftools_* (disabled): almost no distros install these, many have
        rather generic names, we were missing installing new ones,
        upstream ffmpeg does not even have an install target for them,
        and a global USE_EXPAND for this feels wasteful (*could* consider
        adding a all-in-one IUSE=tools if some are wanted by users anyway
        but let us try without and see if anyone complains)
    
      - glslang (disabled): redundant with USE=shaderc and is a pain to
        use directly given glslang often breaks things, esp. worse for
        packages with a slow release cycle and old LTS versions like
        ffmpeg (bug #918989, bug #920283, bug #922333, bug #922433) --
        upstream also seems to favour shaderc: "libshaderc and libglslang
        are mutually exclusive, if in doubt, disable libglslang"
        (from ./configure)
    
      - harcoded-tables (disabled): off by default upstream and listed as a
        "experts only" option that seemingly provide little gains for a
        notable size increase, do not believe it is worth exposing as a USE
    
      - iconv (enabled): virtual/libiconv is essentially free anywhere but
        prefix and disabling iconv can be rather broken for a few things
    
      - network (enabled): no dependencies, fairly small, and many revdeps
        likely expect it to be enabled and just missing the [network]
        (tempting to do the same with USE=postproc but it would still be
        conditional through USE=gpl and be more confusing, and then forcing
        GPL also has its own issues)
    
      - oss (auto): does not have a dedicated option and just checks
        linux-headers and is very small, hardly anyone need this
        but that argument could be applied to a *ton* of in/outdevs,
        filters, de/encoders, and such and we would never see the end
        of it
    
      - pic (enabled): makes little sense not to enable nowadays and
        handles bug #903754 + bug #916067 -- USE had the secondary
        effect of disabling x86-32 asm which still doing given it is
        difficult to support either way due to textrels and
        >=binutils-2.41's enforcing (bug #916067, bug #920808), and
        it is possibly broken for older hardware (bug #733556) -- as
        a minor bonus, this should also let LTO work with abi_x86_32
        (bug #654118)
    
      - static-libs (disabled): cannot think of much of a use for this
        esp. given how massive these libraries are and it would still
        require to link with all its shared-only dependencies
    
      - test (irrelevant): tests are not gone but there is no dependencies
        (bc and wget are not needed) nor REQUIRED_USE to handle anymore,
        thus USE is useless
    
      - threads (auto): no real sense in disabling (bug #868471), and
        leaving it auto let ffmpeg figure out the right implementation
        to use which in most cases means default --enable-pthreads
    
      - cpu_flags_* + cpudetection (enabled): tentatively anyway, just
        let ffmpeg do its thing normally -- simplifies the ebuild a lot,
        "should" fix bug #915384, and also handles whatever ebuild
        was doing wrong wrt bug #752507 + bug #778035 (one minor "issue"
        however is that all these flags being removed will leave users
        confused as to what happened, if reading this and worried about
        optimizations.. then no they are *not* disabled, and it is fine
        for other machines thanks to detection at runtime)
    
    * New IUSE:
    
      - openmpt: requested in bug #921313
    
      - npp: requested in bug #695210 -- note have not tested the
        arm64 (sbsa) support, but it should work in theory as cuda
        toolkit does install npp prebuilt arm64 libraries
    
      - rabbitmq: trivial, may as well add support
    
      (meant to add more but others did not fare as well and will leave
      for later rather than during big changes, kept some minor notes in
      the ebuild about things still not supported)
    
    * Renamed IUSE:
    
      - mp3->lame: this is only for encoding but it made it "sound"
        needed for decoding (not the only case like this but this one
        felt too generic), may surprise those that had it actually
        enabled for encoding
    
      - libxml2->xml and libdrm->drm: given newly enabling these by
        default (see below), it's a good occasion to rename to the
        more commonly used USE without causing issues
    
      - libv4l->v4l: to be precise IUSE=v4l was removed and it gained
        the meaning that IUSE=libv4l had -- old v4l is always enabled
        (if linux) due to the hard dependency on linux-headers (see below)
        -- given the old REQUIRED_USE with libv4l? ( v4l ), all users of
        libv4l will have the new USE enabled already
    
      - libdvdnav+libdvdread->dvd(combined): similar to mpv, simpler
        for users when they just want dvds to work than worry about
        each library (dvd support is new in ffmpeg-7, so this only
        ever been masked)
    
    * Enable a few extra IUSE by default that, while not everyone needs,
      are useful and have dependencies that many users will already have.
    
      - libass,truetype,fontconfig: for proper text/subtitles drawing
        (kdenlive also wants [libass]), albeit video players tend to
        have their own handling (that pull the same depdencies)
    
      - drm: used in various pieces of code and little reason to
        disable when mesa depends on libdrm either way
    
      - xml: needed for DASH-type streams, notably used by youtube,
        and about everyone has libxml2
    
      (one downside of new defaults is MULTILIB_USEDEP, users that only
      selectively enable abi_x86_32 rather than globally may be faced with
      conflicts when updating)
    
    * Always depend on linux-headers if linux, not *required* (except for
      v4l) but this prevents a lot of automagic and going through alternate
      code paths if missing (also go with >=6 which is needed for v4l2m2m
      and I believe also USE=soc for v4l2request)
    
    * Add missing vulkan-headers dependency wrt bug #865201, and also
      opencl-headers wrt bug #941506 (not 100% sure that this is what
      happened for the latter, but given binhost is setup it is likely).
    
    * Bump nv-codec-headers min req to 12.1.14.0, while not *required*
      it spares us for setting up ranges and 11.x is due for cleanup.
    
    * Add missing x11-base/xorg-proto wrt bug #934196 -- technically
      was longer an issue given libX11 RDEPENDs on it "now", but would
      still rather keep these for now.
    
    * Depend on >=librsvg-2.52 wrt bug #918613, USE=svg is not essential
      for arches without rust and upstream bug been went 1.5 years without
      activity.
    
    * Update REQUIRED_USE a bit, cuda does not *need* nvenc (just get
      one filter in less), libplacebo does nothing without sdl(ffplay)
      or vulkan, and few others like these (likely still missing some).
    
    * Drop musl HAVE_POSIX_IOCTL workaround, this is automatically set by
      ./configure since ffmpeg-7.1. However, note that there is another
      related issue with libv4l (not v4l) that is not fixed (bug #911499).
    
    * No longer ignore ffmpeg-spec-disposition test, fixed in 7.1.1.
    
    * Fix verify-sig paths on prefix wrt bug #947253 (untested)
    
    * No longer pass e.g. --disable-indev=alsa when already doing
      --disable-alsa, ./configure seem to figure this out just fine.
    
    * No longer pass --cpu, this expects the -march=<exact> reported by
      the compiler or probes compiler with =native if =host), however it
      does not account for -mno-* both passed or implied by =native and
      could enable things it shouldn't. Furthermore, it adds -march=<exact>
      after the users' -march=native (which is more correct, can enable
      or disable additional features). This option only seem like trouble
      and likely does not get tested much. Removing also handles
      bug #830165 albeit ffmpeg-chromium is still affected.
    
    * Replace EXTRA_FFMPEG_CONF by EXTRA_ECONF, while it is not using
      econf nor autoconf, the latter is more widely known while the former
      needs users to look at the ebuild -- also die if old variable is set
      so users know about this change.
    
    * Skip installing doc/*.txt, that seems mostly oriented at ffmpeg devs,
      and feels noisy in the docdir, but do keep doc/APIChanges
    
    * Replace all *GPL* by the + version given ./configure always output
      with "or later" when listing the final license.
    
    * Maybe not best way to go about this, but when doing incompatible
      --enable-gpl --enable-nonfree, on top of the RESTRICT="bindist"
      also add "all-rights-reserved" so a typical freedom ACCEPT_LICENSE
      can block it.
    
    * Rearrange chromium patch a bit to need less ebuild logic, and make
      it unused for ffmpeg-compat.
    
    * Drop EGIT_MIN_CLONE_TYPE, shallow clones seem fine now? If not,
      could consider just using the official github mirror by default.
    
    List of closed bugs may not be complete, plans are to recheck
    still-open bugs after this is merged.
    
    Bug: https://bugs.gentoo.org/830165
    Closes: https://bugs.gentoo.org/654118
    Closes: https://bugs.gentoo.org/695210
    Closes: https://bugs.gentoo.org/733556
    Closes: https://bugs.gentoo.org/752507
    Closes: https://bugs.gentoo.org/770439
    Closes: https://bugs.gentoo.org/778035
    Closes: https://bugs.gentoo.org/865201
    Closes: https://bugs.gentoo.org/868471
    Closes: https://bugs.gentoo.org/903754
    Closes: https://bugs.gentoo.org/915384
    Closes: https://bugs.gentoo.org/916067
    Closes: https://bugs.gentoo.org/918613
    Closes: https://bugs.gentoo.org/918989
    Closes: https://bugs.gentoo.org/920283
    Closes: https://bugs.gentoo.org/920808
    Closes: https://bugs.gentoo.org/921313
    Closes: https://bugs.gentoo.org/922333
    Closes: https://bugs.gentoo.org/922433
    Closes: https://bugs.gentoo.org/934196
    Closes: https://bugs.gentoo.org/941506
    Closes: https://bugs.gentoo.org/947253
    Signed-off-by: Ionen Wolkens <ionen@gentoo.org>

 media-video/ffmpeg/ffmpeg-9999.ebuild      | 1014 +++++++++++++---------------
 media-video/ffmpeg/files/chromium-r3.patch |   53 ++
 media-video/ffmpeg/metadata.xml            |    8 +
 3 files changed, 538 insertions(+), 537 deletions(-)