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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel