| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
* commit '27079a426c9d3db918b158976e44b9b143d78e1c':
buffer: convert to stdatomic
Merged-by: Clément Bœsch <u@pkh.me>
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
USE_ATOMICS is only set if there is no thread implementation enabled, in
which case you can't expect any lock mechanism from FFmpeg.
This is also conflicting with the incoming use of stdatomic.
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '24a362569bff1d4161742fffaca80a4a4428be8a':
buffer: fix av_buffer_realloc() when the data is offset wrt buffer start
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In such a case behave as if the buffer was not reallocatable -- allocate a
new one and copy the data (preserving just the part described by the
reference passed to av_buffer_realloc).
CC: libav-stable@libav.org
Reported-By: wm4 <nfxjfg@googlemail.com>
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '721a4efc0545548a241080b53ab480e34f366240':
buffer: add support for pools using caller data in allocation
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
| |
| |
| |
| | |
This should allow using more complex allocators than simple malloc
wrappers.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
av_buffer_make_writable()
This allows making a AVBufferRef writable without the need to
update all pointers to it
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
av_buffer_realloc()
This allows reallocating AVBufferRefs without the need to update
all pointers to it
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| | |
ensure sync types arent mixed by mistake
Fixes CID1257011
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| | |
with it
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'fbd6c97f9ca858140df16dd07200ea0d4bdc1a83':
lavu: fix memory leaks by using a mutex instead of atomics
Conflicts:
libavutil/buffer.c
The atomics code is left in place as a fallback for synchronization in the
absence of p/w32 threads. Our ABI did not requires applications to
only use threads (and matching ones) to what libavutil was build with
Our code also was not affected by the leak this change fixes, though
no question the atomics based implementation is not pretty at all.
First and foremost the code must work, being pretty comes after that.
If this causes problems, for example when libavutil is used by multiple
applications each using a different kind of threading system then the
default possibly has to be changed to the uglier atomics.
See: cea3a63ba3d89d8403eef008f7a7c54d645cff70
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The buffer pool has to atomically add and remove entries from the linked
list of available buffers. This was done by removing the entire list
with a CAS operation, working on it, and then setting it back again
(using a retry-loop in case another thread was doing the same thing).
This could effectively cause memory leaks: while a thread was working on
the buffer list, other threads would allocate new buffers, increasing
the pool's total size. There was no real leak, but since these extra
buffers were not needed, but not free'd either (except when the buffer
pool was destroyed), this had the same effects as a real leak. For some
reason, growth was exponential, and could easily kill the process due
to OOM in real-world uses.
Fix this by using a mutex to protect the list operations. The fancy
way atomics remove the whole list to work on it is not needed anymore,
which also avoids the situation which was causing the leak.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
| |
| |
| |
| |
| |
| | |
This reverts commit 3144440004941aa22ffea9933f5e5dfe826df654.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| | |
new function allows to unref buffer and obtain its data.
Signed-off-by: Lukasz Marek <lukasz.m.luki@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Allow single-place definition of constant used to fill poisoned memory.
|
| |
| |
| |
| |
| |
| | |
This function is quite usefull for debuging
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
Found-by: ubitux
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
Fixed CID991859
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This race will always happen sooner or later in a multi-threaded
environment and it will over time lead to OOM.
This fix works by spinning, there are other ways by which this
can be fixed, like simply detecting the issue after it happened
and freeing the over-allocated memory or simply using a mutex.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| | |
602->442 dezicycles
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '1cec0624d0e6f48590283a57169b58b9fe8449d3':
AVBuffer: add a new API for buffer pools
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
* commit '8e401dbe90cc77b1f3067a917d9fa48cefa3fcdb':
lavu: add a new API for reference-counted data buffers.
Conflicts:
libavutil/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
|