Automatically adding ccs based on suspected regression changelists:

Refactor checks to use a copy of the new logging backend. by jonasolsson@webrtc.org - https://webrtc.googlesource.com/src/+/f8e5c110ee806992f4092220339939fe5c2d3cc9

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

ClusterFuzz testcase 4702986199367680 appears to be flaky, updating reproducibility label.

The suspect CL changed the implementation of the webrtc asserts(RTC_CHECK etc.).
Is there any way to tell the fuzzers that FatalLog() is supposed to be fatal, and make it assign these bugs to whoever triggered the assert?

As it stands I get notified of all the bugs where the fuzzer trigger a check anywhere in WebRTC.

Unable to find actual suspect through code search and also observing no CL's under regression range, hence adding appropriate label and requesting someone from dev team to look in to this issue.

Here are the couple of 'WebRTC' related changes: https://webrtc.googlesource.com/src.git/+log/e61d72b37c64..00c71836144b

Just wondering, if this could be related to your change?

Thank you!

danilchap@, Just wondering, if this could be related to your change?

I'd be surprised if that was the case. Danils change shouldn't alter any behavior as it just replaces our internal Optional with the one from abseil, which it was already an alias for.

By the way, what's the sensible thing to do with bugs that the fuzzer detects but then tags Unreproducible? Do we usually try to reproduce them manually, close and wait for the fuzzer to detect them again or something else?

As Jonas mention, this failure shouldn't be related to my changes.

Reading code, failing check is an assumption RTT (round trip time) can't be measured as negative.

+honghaiz@ as owner of p2p - code under test in this fuzzer
+nisse@ who added the failing check

Note that my change was replacing an ASSERT(false) with RTC_NOTREACHED.

My guess is that this is a genuine DoS bug; it looks like we compare current system time to a value received from the untrusted network, and then anything is possible.

I'm not familiar with the code, but maybe the right thing is to simply ignore received timestamps that are out of range, possibly with a log message.

Yeah, RTC_NOTREACHED seems like the wrong tool to use here.

As far as I can tell we're not using the RTT estimate for anything here and we should set it on the first valid ack, so continuing on should be safe. We could just remove the entire else clause, or change it to a RTC_D?LOG, probably at the LS_WARNING level?

I agree.

Some log message sounds reasonable.

Log message it is, then: https://webrtc-review.googlesource.com/c/src/+/96880

The CL just landed, and with that I consider this bug resolved.

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/11a922086bea634f95661434278b8b95fef60b04

commit 11a922086bea634f95661434278b8b95fef60b04
Author: Jonas Olsson <jonasolsson@webrtc.org>
Date: Wed Sep 05 13:05:05 2018

Demote RTC_NOTREACHED in pseudotcp RTT processing to warning.

This problem shouldn't be severe enough to require a crash, and it can be triggered by untrusted network data.
We'll print a warning instead.

Bug:  chromium:877790 
Change-Id: Ie1f33d85dc7f0ccbbc1d027b73f77b964c6f7e46
Reviewed-on: https://webrtc-review.googlesource.com/96880
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24579}
[modify] https://crrev.com/11a922086bea634f95661434278b8b95fef60b04/p2p/base/pseudotcp.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/44a088148ad093af79f24aab6f3b9ab3ce68219f

commit 44a088148ad093af79f24aab6f3b9ab3ce68219f
Author: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Wed Sep 05 18:27:42 2018

Roll src/third_party/webrtc e10f3b7403d0..62228c41ea17 (3 commits)

https://webrtc.googlesource.com/src.git/+log/e10f3b7403d0..62228c41ea17


git log e10f3b7403d0..62228c41ea17 --date=short --no-merges --format='%ad %ae %s'
2018-09-05 magjed@webrtc.org Reland "Add tool for aliging video files"
2018-09-05 jonasolsson@webrtc.org Demote RTC_NOTREACHED in pseudotcp RTT processing to warning.
2018-09-05 henrika@webrtc.org Adds stream-switch support in new Windows ADM.


Created with:
  gclient setdep -r src/third_party/webrtc@62228c41ea17

The AutoRoll server is located here: https://autoroll.skia.org/r/webrtc-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_archive_rel_ng;luci.chromium.try:mac_chromium_archive_rel_ng

BUG= chromium:877790 
TBR=webrtc-chromium-sheriffs-robots@google.com

Change-Id: I46401530f62b12518d55b6968d3cdab6e3b10d23
Reviewed-on: https://chromium-review.googlesource.com/1207152
Reviewed-by: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#588943}
[modify] https://crrev.com/44a088148ad093af79f24aab6f3b9ab3ce68219f/DEPS