Registers transport on construction removing the need for ViESender as a
hop and removing a potential deadlock by removing RegisterSendTransport.
BUG=1695, 2999
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/57449004
Cr-Commit-Position: refs/heads/master@{#9309}
The roll seems to cause leaks on our Linux Memcheck bot.
Added a suppression needed for Trusty in order to run
memcheck similar to the bot (that runs Precise).
Leave all the other source code edits from r8596 in place.
See also http://chromegw/i/client.webrtc/builders/Linux%20Memcheck/builds/3343TBR=pbos@webrtc.org
TESTED=Can no longer repro memcheck failure with this patch applied:
GYP_DEFINES="build_for_tool=memcheck" webrtc/build/gyp_webrtc
ninja -C out/Release libjingle_peerconnection_unittest
tools/valgrind-webrtc/webrtc_tests.sh --test libjingle_peerconnection_unittest --tool memcheck --target Release --build-dir out --gtest_filter=WebRtcSessionTest.TestIncorrectMLinesInLocalAnswer
Review URL: https://webrtc-codereview.appspot.com/47419004
Cr-Commit-Position: refs/heads/master@{#8612}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8612 4adac7df-926f-26a2-2b94-8c16560cd09d
Without this patch, Valgrind's Memcheck was complaining that the test
for whether we should return -1 following the call to
WebRtcIsac_DecodeLb made a conditional branch or move based on the
value of numSamplesLB, which was uninitialized if WebRtcIsac_DecodeLb
failed.
However, as can be seen in the source, the control flow only depends
on the value of numSamplesLB if numDecodedBytesLB >= 0; i.e., if
WebRtcIsac_DecodeLb returned successfully, in which case numSamplesLB
is always initialized. The discrepancy is due to the fact that
Valgrind works on the generated machine code, which contains spurious
such dependencies. The generated code for this test:
if ((numDecodedBytesLB < 0) || (numDecodedBytesLB > lenEncodedLBBytes) ||
(numSamplesLB > MAX_FRAMESAMPLES)) {
looks like this:
95: 0f bf 45 d6 movswl -0x2a(%rbp),%eax
99: 3d c0 03 00 00 cmp $0x3c0,%eax
9e: 0f 8f 45 01 00 00 jg 1e9 <Decode+0x1e9>
a4: 44 89 f0 mov %r14d,%eax
a7: c1 e0 10 shl $0x10,%eax
aa: 0f 88 39 01 00 00 js 1e9 <Decode+0x1e9>
b0: 41 0f bf ce movswl %r14w,%ecx
b4: 89 8d 98 e1 ff ff mov %ecx,-0x1e68(%rbp)
ba: 41 0f bf c7 movswl %r15w,%eax
be: 39 c1 cmp %eax,%ecx
c0: 0f 8f 23 01 00 00 jg 1e9 <Decode+0x1e9>
Note how the compiler has seemingly ignored the C language's guarantee
that the arguments to || must be evaluated in left-to-right order, and
compares numSamplesLB (%eax) with MAX_FRAMESAMPLES (0x3c0, a.k.a. 960)
before the other two conditions! If the uninitialized value in
numSamplesLB happens to be greater than 960, we'll jump to
Decode+0x1e9 (where we'll return -1) without even looking at the other
two conditions. Has the compiler generated broken code?
Well, no. If numDecodedBytesLB is < 0 so that numSamplesLB is
uninitialized, we'll end up jumping to 1e9 whether that value is
greater than 960 or not; we'll just do it with different jump
instructions. This is entirely invisible as far as the C language is
concerned, but the dependency on the uninitialized value is visible at
the machine code level, which is why Memcheck complains.
This patch solves the problem by pragmatically initializing
numSamplesLB before the call even though it isn't necessary other than
for placating Memcheck.
BUG=4143
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36309004
Cr-Commit-Position: refs/heads/master@{#8492}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8492 4adac7df-926f-26a2-2b94-8c16560cd09d
This test is too slow to execute:
[ RUN ] EndToEndTest.SendsAndReceivesH264
e:\b\build\slave\win-drmem\build\src\webrtc\video\end_to_end_tests.cc(287): error: Value of: Wait()
Actual: 3
Expected: kEventSignaled
Which is: 1
Timed out while waiting for enough frames to be decoded.
[ FAILED ] EndToEndTest.SendsAndReceivesH264 (72812 ms)
BUG=3159
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38599004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8063 4adac7df-926f-26a2-2b94-8c16560cd09d
Reason: Turns out this does not solve the problem as the buildbots
run into another error later on during collecting gtest output.
The problem is solved by excluding these bots from flakiness dashboard
data instead, in https://codereview.chromium.org/705913002/
> Fix memcheck and dr memory after flakiness dashboard deployment.
>
> I deployed buildbot configuration for uploading data to the
> flakiness dashboard but I didn't predict our Dr Memory and
> Memcheck bots would fail due to the new flag passed to the test.
> Adding the --gtest_output flag to the script will avoid the build
> to fail as a workaround.
>
> TBR=andrew@webrtc.org
> TESTED=Passing test run using:
> src/tools/valgrind-webrtc/webrtc_tests.sh --test audio_decoder_unittests --tool memcheck --target Release --build-dir src/out --gtest_output=xml:audio_decoder_unittests.xml
>
> BUG=
>
> Review URL: https://webrtc-codereview.appspot.com/28999004TBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31969004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7643 4adac7df-926f-26a2-2b94-8c16560cd09d
I deployed buildbot configuration for uploading data to the
flakiness dashboard but I didn't predict our Dr Memory and
Memcheck bots would fail due to the new flag passed to the test.
Adding the --gtest_output flag to the script will avoid the build
to fail as a workaround.
TBR=andrew@webrtc.org
TESTED=Passing test run using:
src/tools/valgrind-webrtc/webrtc_tests.sh --test audio_decoder_unittests --tool memcheck --target Release --build-dir src/out --gtest_output=xml:audio_decoder_unittests.xml
BUG=
Review URL: https://webrtc-codereview.appspot.com/28999004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7642 4adac7df-926f-26a2-2b94-8c16560cd09d
This is to get the DrMemory Full bots to go green, this was previously
suppressed. This fix is likely hiding a real bug that should be
investigated, but it's not a regression from before. The issue should
not be closed before we figure out why this is the case and revert this
"fix".
TBR=stefan@webrtc.org
BUG=3183
Review URL: https://webrtc-codereview.appspot.com/30369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7169 4adac7df-926f-26a2-2b94-8c16560cd09d
Reports uninitialized-memory reads that seem to originate from when the
frame is copied. The test passes if we remove CPU optimizations from
libyuv, disabling test until we figure out whether it's an unsupported
instruction in DrMemory, bug in libyuv or bug in the test.
BUG=3754
R=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19149004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6995 4adac7df-926f-26a2-2b94-8c16560cd09d
