Exclude failing tests in libjingle tests and suppress
failures in modules_unittests.
Also exclude the following extremely slow tests to make it
possible to get a reasonable execution time for the bot:
* TestScaler.PointScaleTest (81573 ms)
* TestScaler.BiLinearScaleTest (1111554 ms)
* TestScaler.BoxScaleTest (1129625 ms)
* TestVp8Impl.BaseUnitTest (762598 ms)
* VideoProcessorIntegrationTest.ProcessNoLossChangeBitRate (342149 ms)
TBR=phoglund@webrtc.org
BUG=3158, 3183, 3184
TEST=Successful runs on local Windows box:
tools\valgrind-webrtc\webrtc_tests.bat --build-dir out --target Debug --test libjingle_p2p_unittest --tool drmemory_full
tools\valgrind-webrtc\webrtc_tests.bat --build-dir out --target Debug --test libjingle_peerconnection_unittest --tool drmemory_full
tools\valgrind-webrtc\webrtc_tests.bat --build-dir out --target Debug --test modules_unittests --tool drmemory_full
Review URL: https://webrtc-codereview.appspot.com/11819004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5888 4adac7df-926f-26a2-2b94-8c16560cd09d
With these tests excluded and failures suppressed
we should be able to bring Dr Memory Full into a
green state in
http://build.chromium.org/p/client.webrtc.fyi/waterfall
so we can move the bots into the main waterfall.
BUG=3158, 3159
TEST=Ran successful runs of the tests that never completed
using the reproduction steps in the issues listed above on
a local Windows box. The tests that just failed weren't tried,
since they cannot have been blocking other possibly failing
tests in the same binary.
R=pbos@webrtc.org
TBR=pbos
Review URL: https://webrtc-codereview.appspot.com/11209004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5850 4adac7df-926f-26a2-2b94-8c16560cd09d
These tests have been failing for a long time at
http://build.chromium.org/p/client.webrtc.fyi/builders/Linux%20TsanRV
This bot runs a tool called TSan Race Verifier.
More info about Race Verifiers can be found at
https://code.google.com/p/data-race-test/wiki/RaceVerifier
By excluding the tests like this, they will also be disabled
for the normal TSan bot, where they currently pass. This shouldn't
be a problem since we have a TSan v2 bot running too (which uses
a different set of suppressions), so it should catch any newly
introduced race conditions. The TSan v2 bot will soon replace the
old TSan bot, as v1 is being deprecated.
TBR=mallinath@webrtc.org
BUG=2396
TEST=Passing run on Linux of:
GYP_DEFINES=build_with_tool=tsan gclient runhooks
ninja -C out/Release libjingle_p2p_unittest
tools/valgrind-webrtc/webrtc_tests.sh --tool=tsan_rv -b out/Release -t libjingle_p2p_unittest
Review URL: https://webrtc-codereview.appspot.com/8329005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5515 4adac7df-926f-26a2-2b94-8c16560cd09d
New errors arrived when rolling libjingle in r5502.
These suppressions are needed to green up the Memcheck and
TSan bots.
BUG=1976,2080
TEST=local runs on Linux:
tools/valgrind-webrtc/webrtc_tests.sh --tool=tsan -b out/Release -t libjingle_unittest
tools/valgrind-webrtc/webrtc_tests.sh --tool=memcheck -b out/Release -t libjingle_unittest
and trybot:
git try --bot=linux_memcheck,linux_tsan -t libjingle_unittest
TBR=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5509 4adac7df-926f-26a2-2b94-8c16560cd09d
Chromium has decided to drop Coverity so
we don't have any reason for maintaining this code.
Personally, I think that from a quality perspective other tools,
like all the new compiler warnings that are constantly being added
to the Clang compiler is a better way to address dangers in the code.
The maintenance cost and overhead of such advanced tools like Coverity
is simply too high.
BUG=
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7669007
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5500 4adac7df-926f-26a2-2b94-8c16560cd09d
1) Change AsyncSocket's SignalReadEvent and SignalWriteEvent's thread mode to multi_threaded_local as they can be accessed from different threads.
2) Protect NATServer::TransEntry::whitelist.
3) Protect PhysicalSocket:error_.
Detail failures can be seen from issue 2080, comment #5.
TBR=fischman@webrtc.org
RISK=P1
TEST=try bots and tsanv2
BUG=2080
Review URL: https://webrtc-codereview.appspot.com/2669005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5026 4adac7df-926f-26a2-2b94-8c16560cd09d
1) init start_time_ns_ before the file_read_thread_ is started to avoid data racing as the start_time_ns_ will also be read by the file_read_thread_.
2) add CriticalSection to protect |finished_| that is accessed by FileReadThread and the main thread
Also remove the suppression for filemediaengine.cc, which has already been fixed in other cl.
TBR=henrike@webrtc.org
TEST=try bots and manual tsan v2 test
BUG=2078
Review URL: https://webrtc-codereview.appspot.com/2509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5018 4adac7df-926f-26a2-2b94-8c16560cd09d
Update Thread documentation, fix all subclasses that had a problem.
This is to avoid a data racing between the destructor modifying the vtable, and
Thread::PreRun calling virtual method Run at the same time.
For example:
[ RUN ] FileMediaEngineTest.TestGetCapabilities
==================
WARNING: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call) (pid=2967)
Read of size 8 at 0x7d480000bd00 by thread T1:
#0 talk_base::Thread::PreRun(void*) /mnt/data/b/build/slave/Linux_Tsan_v2/build/src/out/Release/../../talk/base/thread.cc:353 (libjingle_media_unittest+0x000000234da8)
Previous write of size 8 at 0x7d480000bd00 by main thread:
#0 talk_base::Thread::~Thread() /mnt/data/b/build/slave/Linux_Tsan_v2/build/src/out/Release/../../talk/base/thread.cc:158 (libjingle_media_unittest+0x00000023478c)
#1 ~RtpSenderReceiver /mnt/data/b/build/slave/Linux_Tsan_v2/build/src/out/Release/../../talk/media/base/filemediaengine.cc:122 (libjingle_media_unittest+0x0000001b551f)
...
RISK=P2
TESTED=try bots and tsan
BUG=2078,2080
R=fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2428004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4999 4adac7df-926f-26a2-2b94-8c16560cd09d
Turns out I was running libjingle_unittest
instead of libjingle_peerconnection_unittest
on the bot machine when I was verifying the
suppressions added in r4991 on the bot.
This will hopefully be the last round.
BUG=2528
TEST=running libjingle_unittest with these
suppressions applied locally on the bot.
TBR=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2426004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4993 4adac7df-926f-26a2-2b94-8c16560cd09d
Since we don't have a trybot for LSan, this is the only
way to resolve errors only happening on the bots
(except running at the bot themselves).
I suspect some errors only occurs on the bots since
the compiler version differs (4.6 on bots, 4.6.3 on
my machine).
This last suppressions round was tested on an actual
Chrome infra VM as well, with no errors.
BUG=2528
TEST=ran successfully on the bot.
TBR=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2424004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4991 4adac7df-926f-26a2-2b94-8c16560cd09d
The suppressions in r4988 were not enough to green
up the LSan+ASan bot.
Here's another round of suppressions to get the bot green
which I have tested multiple runs without any leaks reported.
BUG=2527,2528
TEST=
GYP_DEFINES='asan=1 lsan=1 linux_use_tcmalloc=0 release_extra_cflags="-gline-tables-only"' gclient runhooks
ninja -C out/Release libjingle_unittest
export ASAN_SYMBOLIZER_PATH=`(pwd)`/third_party/llvm-build/Release+Asserts/bin/llvm-symbolizer
export ASAN_OPTIONS="detect_leaks=1 strict_memcmp=0"
export LSAN_OPTIONS="suppressions=tools/lsan/suppressions.txt"
out/Release/libjingle_peerconnection_unittest
out/Release/libjingle_unittest
TBR=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2422004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4990 4adac7df-926f-26a2-2b94-8c16560cd09d
