[FFmpeg-devel] [PATCH] submit_thread should also lock the mutex that guards the source avctx (prev_thread->avctx) when calling update_context_from_thread.

James Almer jamrial at gmail.com
Fri Feb 26 03:50:28 CET 2016


On 2/25/2016 11:32 PM, Wan-Teh Chang wrote:
> This is because the codec->decode() call in frame_worker_thread may be
> modifying that avctx at the same time. This data race is reported by
> ThreadSanitizer.
> 
> Although submit_thread holds two locks simultaneously, it always
> acquires them in the same order because |prev_thread| is always the
> array element before |p| (with a wraparound at the end of array), and
> submit_thread is the only function that acquires those two locks, so
> this won't result in a deadlock.

Did you try running the FATE suite using threadsanitizer, or just decoded random
videos? I remember like half the tests were failing because of data races and
most of them pointed to code changed by your patches. It would be interesting to
see how they are affected.
configure has the --toolchain=gcc-tsan option for this. Make sure to also add
--disable-stripping, then run "make fate THREADS=4 SAMPLES=/path/to/samples" or
similar. You may instead want to run a small set at a time instead of the whole
suite since it's big and threadsanitizer slow. Try for example fate-h264 in that
case.

Thanks for working on this.


More information about the ffmpeg-devel mailing list