On Aug 25, 2011, at 9:15 PM, Sean McGovern wrote: > On Thu, Aug 25, 2011 at 8:01 PM, Aaron Colwell <[email protected]> wrote: >> Hi, >> I started a thread with the following message on the FFmpeg-devel list and >> someone suggested that I start a discussion on this list as well. Any help >> you could provide would be greatly appreciated. >> Thanks, >> Aaron >> >> ---------- Forwarded message ---------- >> From: Aaron Colwell <[email protected]> >> Date: Thu, Aug 25, 2011 at 11:26 AM >> Subject: Race conditions in libavcodec/pthread.c >> To: [email protected] >> >> >> Hi, >> Some recent changes to Chromium unit tests have caused FFmpeg decoding to >> get regularly scrutinized by our ThreadSanitizer tool. This has led to the >> detection of a variety of race conditions in libavcodec/pthread.c . Quick >> inspection of the code reveals that there is significant use of the >> "double-checked locking" anti-pattern and inconsistent use of >> PerThreadContext::mutex and PerThreadContext::progress_mutex which are >> likely causing of most of the race conditions. I wanted to ask a few >> questions before jumping in and trying to fix this. >> 1. Are you already aware of these issues? >> 2. Is someone already working on fixing these? >> 3. Who is the expert on libavcodec/pthread.c so I can direct questions to >> them? >> 4. Why is "double-checked locking" being used? Will there be significant >> protest if I remove it? >> 5. What is the relationship between PerThreadContext::mutex >> & PerThreadContext::progress_mutex and what member variables are they >> supposed to protect? I've seen cases where only mutex is held, mutex & >> progress_mutex are held, and only progress_mutex is held. At times these 3 >> cases appear to modify the same state variables. ThreadSanitizer is getting >> stuck on some test runs now which leads me to believe that there is a >> locking pattern that results in deadlock. >> 6. Is someone else interested in tackling this? >> Thanks, >> Aaron >> >> _______________________________________________ >> libav-devel mailing list >> [email protected] >> https://lists.libav.org/mailman/listinfo/libav-devel >> >> > > Hi Ronald, > > Could this issue possibly be the cause of the > (h264-conformance-mr3_tandberg_b && threads == 2) failures?
This isn't actually a multithreading issue (if you disable concurrency it reproduces), it's just that buffer management works differently with threading on, and some frames have to stay around in the buffer for a bit longer. MAX_BUFFERS is set to 33 - the theoretical limit with threading on. This clip is supposed to reach that limit, but instead it seems to go 1 past it. Seems like some unused frame isn't being released immediately as it should be. In the name of perfection I wanted to find the actual cause instead of making MAX_BUFFERS unnecessarily large, but haven't yet. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
