The --close-previous-roll makes it possible to always
close a previously created roll when creating a new one.
This way it will be possible to avoid getting a pile of
open CLs created and never closed for all failed
roll attempts, which is useful for automation.
I also moved some variables out of the AutoRoller
class that doesn't neeed to be there.
BUG=chromium:433305
TESTED=Ran:
tools/autoroller/roll_webrtc_in_chromium.py --verbose --close-previous-roll
and verified it actually closed an existing roll.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40349004
Cr-Commit-Position: refs/heads/master@{#8726}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8726 4adac7df-926f-26a2-2b94-8c16560cd09d
Add a --wait-for-trybots flag that will have the script look for
a previously created roll and poll the trybot status until at least
one trybot has failed or all have compelted successfully.
BUG=chromium:433305
TESTED=Ran:
tools/autoroller/roll_webrtc_in_chromium.py --chromium-checkout /ssd/chrome/src --verbose
tools/autoroller/roll_webrtc_in_chromium.py --chromium-checkout /ssd/chrome/src --verbose --wait-for-trybots
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45659004
Cr-Commit-Position: refs/heads/master@{#8718}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8718 4adac7df-926f-26a2-2b94-8c16560cd09d
Send the created CL to the CQ right away upon creation.
Add a --no-commit flag that can be specified to avoid that.
Remove the trybot status feature (--status) and the commit CL
feature (--commit).
BUG=chromium:433305
TESTED=Ran:
tools/autoroller/roll_webrtc_in_chromium.py --chromium-checkout /ssd/chrome/src --dry-run --ignore-checks
and verified it didn't trigger tryjobs or sent to CQ. Then I ran:
tools/autoroller/roll_webrtc_in_chromium.py --chromium-checkout /ssd/chrome/src --ignore-checks
and verified it was sent to CQ.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42739004
Cr-Commit-Position: refs/heads/master@{#8715}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8715 4adac7df-926f-26a2-2b94-8c16560cd09d
* Add optional --chromium-checkout flag to point out the Chromium checkout to
work in (automatic fallback to current working dir if that's a Chromium checkout).
* Introduce logging and --verbose flag.
* Make functions private and adopt Python style guide.
* Made --dry-run perform the presubmit checks and other stuff for --commit, except the actual commit.
* Add EDITOR=true environment to 'git cl upload' to avoid launching an interactive editor.
* Removed interactive invocation of 'git cl upload' and 'git cl land'
BUG=chromium:433305
TESTED=Muliple local runs using:
tools/autoroller/roll_webrtc_in_chromium.py --chromium-checkout /path/to/chrome/src --dry-run --verbose
tools/autoroller/roll_webrtc_in_chromium.py --chromium-checkout /path/to/chrome/src --dry-run --abort
tools/autoroller/roll_webrtc_in_chromium.py --chromium-checkout /path/to/chrome/src --dry-run --status
cd /path/to/chrome/src
/path/to/webrtc/src/tools/autoroller/roll_webrtc_in_chromium.py --dry-run --verbose
R=phoglund@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46559004
Cr-Commit-Position: refs/heads/master@{#8694}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8694 4adac7df-926f-26a2-2b94-8c16560cd09d
Adding a pristine copy (only changed license and ownerless
TODOs) of the script we've used to roll the WebRTC revision
in Chromium DEPS.
This script assumes being located inside a Chromium checkout,
so a follow-up CL will be created for review of the required
changes for that before it can be used.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47499004
Cr-Commit-Position: refs/heads/master@{#8675}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8675 4adac7df-926f-26a2-2b94-8c16560cd09d
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
Add third_party/instrumented_libraries to setup_links.py
Add tools/msan/blacklist.txt which is the default location used
by MSan.
These changes are prerequisites to be able to use MSan with WebRTC.
To use it, one must also run:
sudo third_party/instrumented_libraries/install-build-deps.sh
to get the instrumented libraries installed (requires
/etc/apt/sources.list to be setup with deb-src entries).
NOTICE: Compilation is not yet working, but with this we can setup
a FYI bot to work with.
BUG=chromium:416871
TESTED=gclient sync + generate projects using:
GYP_DEFINES='msan=1 use_instrumented_libraries=1 instrumented_libraries_jobs=20' webrtc/build/gyp_webrtc
Built successfully in Release and ran a couple of tests (some crashed, some passed).
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/25649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7352 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
