1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-12 19:18:44 +02:00
Commit Graph

10 Commits

Author SHA1 Message Date
Timo Rothenpieler
7945d30e91 avutil/mem: limit alignment to maximum simd align
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.

This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.

Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.

This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.
2024-02-27 19:41:09 +01:00
Timo Rothenpieler
4618b5ebb9 Revert "avutil/mem: limit alignment to maximum simd align"
Patch was not intended to be part of the set it got pushed with.

This reverts commit 6154137b18.
2024-02-09 20:20:03 +01:00
Timo Rothenpieler
6154137b18 avutil/mem: limit alignment to maximum simd align
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.

This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.

Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.

This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.
2024-02-09 18:11:49 +01:00
James Almer
21814a70db avutil: remove FF_API_DECLARE_ALIGNED
Signed-off-by: James Almer <jamrial@gmail.com>
2023-02-09 15:35:14 +01:00
Andreas Rheinhardt
0bb0c26799 avutil/mem_internal: Fix headers
Including avassert.h is unnecessary since commit
786be70e28.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2022-08-24 03:43:52 +02:00
James Almer
786be70e28 avutil/mem: make ff_fast_malloc() internal to mem.c
Signed-off-by: James Almer <jamrial@gmail.com>
2021-05-27 10:29:52 -03:00
Anton Khirnov
e15371061d lavu/mem: move the DECLARE_ALIGNED macro family to mem_internal on next+1 bump
They are not properly namespaced and not intended for public use.
2021-01-01 14:14:57 +01:00
Anton Khirnov
c8c2dfbc37 lavu: move LOCAL_ALIGNED from internal.h to mem_internal.h
That is a more appropriate place for it.
2021-01-01 14:11:01 +01:00
James Almer
39a04ebcaf avutil/mem_internal: add missing header includes
Fixes make checkheaders

Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
2015-07-13 21:54:15 -03:00
Michael Niedermayer
d6ff68ad85 Factor duplicated ff_fast_malloc() out into mem_internal.h
internal.h is difficult to use due to circular dependancies
mem.h is a public header ff_* is not public
Alternative solutions probably are possible too

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2015-07-13 02:41:43 +02:00