reimaginemedia / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

libvpx race condition caused by vp9_reconintra.c #962

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What is the expected behavior? What do you see instead?
The WebRTC test 'video_engine_tests' started reporting data races under TSan v2 
after updating the libvpx revision from 33bbffe to 080710f. See 
https://webrtc-codereview.appspot.com/43519004/ for our roll-CL.

A failing tryjob with full logs can be found at 
http://build.chromium.org/p/tryserver.webrtc/builders/linux_tsan2/builds/3761/st
eps/video_engine_tests/logs/stdio
(same log attached)

What version are you using? On what operating system?
Linux Precise (can repro on Trusty as well).

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?

I can repro on Trusty using:
mkdir checkout
cd checkout
fetch webrtc
cd src
GYP_DEFINES='tsan=1 release_extra_cflags=-g use_allocator=none' 
webrtc/build/gyp_webrtc
ninja -C out/Release video_engine_tests
TSAN_OPTIONS=detect_deadlocks=0 symbolize=1 
external_symbolizer_path=`pwd`/third_party/llvm-build/Release+Asserts/bin/llvm-s
ymbolizer out/Release/video_engine_tests 

Please provide any additional information below.

Original issue reported on code.google.com by kjellander@chromium.org on 2 Mar 2015 at 6:29

Attachments:

GoogleCodeExporter commented 9 years ago
Hangyu, any ideas?

Original comment by johannko...@google.com on 2 Mar 2015 at 7:13

GoogleCodeExporter commented 9 years ago
Looks like this may be encoder related. Yunqing, it be good to review the vpx 
unit tests to make sure there's something representative of rtc encodes in 
place. TSan is run across tests with 'Thread' in the name, so this should have 
been caught.

Original comment by jz...@google.com on 2 Mar 2015 at 7:53

GoogleCodeExporter commented 9 years ago
Marco reminded me that the rtc test isn't using multi-threaded encode, but is 
doing multiple encodes in different threads. An encode and decode test that 
does this should be added in libvpx.
Given that, it's likely the cause here is some common data/table being 
initialized.

Original comment by jz...@google.com on 2 Mar 2015 at 8:51

GoogleCodeExporter commented 9 years ago
Please try the patch: https://gerrit.chromium.org/gerrit/#/c/73909/1

Original comment by yunqingw...@google.com on 3 Mar 2015 at 5:00

GoogleCodeExporter commented 9 years ago
Tested the patch in (4) and it fixes the issue. 

Original comment by marpan@google.com on 3 Mar 2015 at 5:44

GoogleCodeExporter commented 9 years ago

Original comment by fgalli...@google.com on 12 Mar 2015 at 10:19