As this breaks the FYI bots in
http://build.chromium.org/p/chromium.webrtc.fyi/waterfall
due to different path to isolate.gypi (which cannot easily
be resolved due to limitations in GYP)
> Isolate GYP target and .isolate files for tests
>
> Implemented according to the instructions at
> http://www.chromium.org/developers/testing/isolated-testing
>
> Workflow has been like this:
> 1. create _run GYP target
> 2. create a stripped down .isolate file
> 3. export GYP_DEFINES="$GYP_DEFINES test_isolation_mode=check"
> 4. runhooks
> 5. compile
> 6. test if the test would run (i.e. find it's dependencies) without
> actually executing it:
> tools/swarm_client/isolate.py run --isolated out/Release/testname.isolated
> 7. If failing, run the fix_test_cases.py script like this:
> tools/swarm_client/fix_test_cases.py --isolated out/Release/testname.isolated
>
> All tests that run on the bots for WebRTC has got _run target
> and .isolate file created.
>
> "Normal tests" that run fine on any machine:
> * audio_decoder_unittests
> * common_audio_unittests
> * common_video_unittests
> * metrics_unittests
> * modules_integrationtests
> * modules_unittests
> * neteq_unittests
> * system_wrappers_unittests
> * test_support_unittests
> * tools_unittests
> * video_engine_core_unittests
> * voice_engine_unittests
>
> Tests that requires bare-metal and audio/video devices:
> * audio_device_integrationtests
> * video_capture_integrationtests
>
> I also added the isolate boilerplate code for the following
> tests that are not yet pure gtest binaries (which means they
> cannot run isolated yet):
> * video_render_integrationtests
> * vie_auto_test
> * voe_auto_test
>
> TEST=running isolate.py as described above.
> BUG=1916
> R=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/1673004TBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2040004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4548 4adac7df-926f-26a2-2b94-8c16560cd09d
Implemented according to the instructions at
http://www.chromium.org/developers/testing/isolated-testing
Workflow has been like this:
1. create _run GYP target
2. create a stripped down .isolate file
3. export GYP_DEFINES="$GYP_DEFINES test_isolation_mode=check"
4. runhooks
5. compile
6. test if the test would run (i.e. find it's dependencies) without
actually executing it:
tools/swarm_client/isolate.py run --isolated out/Release/testname.isolated
7. If failing, run the fix_test_cases.py script like this:
tools/swarm_client/fix_test_cases.py --isolated out/Release/testname.isolated
All tests that run on the bots for WebRTC has got _run target
and .isolate file created.
"Normal tests" that run fine on any machine:
* audio_decoder_unittests
* common_audio_unittests
* common_video_unittests
* metrics_unittests
* modules_integrationtests
* modules_unittests
* neteq_unittests
* system_wrappers_unittests
* test_support_unittests
* tools_unittests
* video_engine_core_unittests
* voice_engine_unittests
Tests that requires bare-metal and audio/video devices:
* audio_device_integrationtests
* video_capture_integrationtests
I also added the isolate boilerplate code for the following
tests that are not yet pure gtest binaries (which means they
cannot run isolated yet):
* video_render_integrationtests
* vie_auto_test
* voe_auto_test
TEST=running isolate.py as described above.
BUG=1916
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1673004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4547 4adac7df-926f-26a2-2b94-8c16560cd09d
When VideoDecoder::Decode, Reset, or Release is called,
VideoCodingModuleImpl::_receiveCritSect may have been
acquired. Decode callback needs to acquire the same lock
in ViEChannel::FrameToRender. It is not a problem for
SW decode because decode callback is run on the same
WebRTC decoding thread and the lock is re-entrant. But
for HW decode, decode callback is run on a thread different
from WebRTC decoding thread. Decode callback gets the locks
in the opposite order. Deadlock can happen.
BUG=http://crbug.com/170345
TEST=Try apprtc.appspot.com/?debug=loopback on ARM Chromebook Daisy.
Run libjingle_peerconnection_unittest.
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1997005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4523 4adac7df-926f-26a2-2b94-8c16560cd09d
Running with a network thread provides a more realistic simulation. Like
a real network, packets are handed off to a socket, or buffer, and then
the call returns. This prevents weird scenarios when both the sending
side and receiving side are on the call stack simultaneously, which can
cause deadlocks as locks could otherwise be taken simultaneously in both
the sender and receiver order by the same thread.
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2000005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4522 4adac7df-926f-26a2-2b94-8c16560cd09d
This version of LoopBackTransport hands packets over to a network thread
which will deliver them instead. This allows SendRTP and SendRTCP to
always be able to return, preventing deadlocks in voe_auto_test. The
previous case did not represent actual network usage. Now the send and
receive side can run concurrently with the receiving side. Previously
the sender thread also drove the receiving side, which does not
represent the regular use case where packets are put on a network
socket.
BUG=1568,2081,2178
TEST=Ran VoiceEngine RtpRtcpTest.*, known for deadlocking, 100+ times.
R=xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1985005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4516 4adac7df-926f-26a2-2b94-8c16560cd09d
When VideoDecoder::Decode, Reset, or Release is called,
VideoCodingModuleImpl::_receiveCritSect may have been
acquired. Decode callback needs to acquire the same lock
in ViEChannel::FrameToRender. It is not a problem for
SW decode because decode callback is run on the same
WebRTC decoding thread and the lock is re-entrant. But
for HW decode, decode callback is run on a thread different
from WebRTC decoding thread. Decode callback gets the locks
in the opposite order. Deadlock can happen.
BUG=http://crbug.com/170345
TEST=Try apprtc.appspot.com/?debug=loopback on ARM Chromebook Daisy.
R=stefan@webrtc.org, wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1977004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4509 4adac7df-926f-26a2-2b94-8c16560cd09d
The complexity of the last ChannelManager and potentially usage of it as well caused race conditions and deadlocks in loopback voe_auto_test. This ref-counted solution takes no long-term locks, uses less locks overall and is significantly easier to understand.
ScopedChannel has been split up into a ChannelOwner with a reference to a channel and an Iterator over ChannelManager. Previous code was really used for both things. ChannelOwner is used as a shared pointer to a channel object, while an Iterator should work as expected.
BUG=2081
R=tommi@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1802004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4502 4adac7df-926f-26a2-2b94-8c16560cd09d
The test works by randomly dropping small bursts of packets until enough
NACKs have been sent back by the receiver. Retransmitted packets are
never dropped in order to assure that all packets are eventually
delivered. When enough NACK packets have been received and all dropped
packets retransmitted, the test waits for the receiving side to send a
number of RTCP packets without NACK lists to assure that the receiving
side stops sending NACKs once packets have been retransmitted.
BUG=2043
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1934004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4482 4adac7df-926f-26a2-2b94-8c16560cd09d
