The SdpOfferAnswerHandler::ssrc_generator_ variable is used from
multiple threads.
Adding thread checks + tests for UniqueNumberGenerator along the way.
Bug: webrtc:12666
Change-Id: Id2973362a27fc1d2c7db60de2ea447d84d18ae3e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214702
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33668}
This is useful to understand how often we block in certain parts of the
api and track improvements/regressions.
There are two macros, both are only active for RTC_DCHECK_IS_ON builds:
* RTC_LOG_THREAD_BLOCK_COUNT()
Example:
void MyClass::MyFunction() {
RTC_LOG_THREAD_BLOCK_COUNT();
thread_->Invoke<void>([this](){ DoStuff(); });
}
When executing this function during a test, the output could be:
(my_file.cc:2): Blocking MyFunction: total=1 (actual=1, would=0)
The words 'actual' and 'would' reflect whether an actual thread switch
was made, or if in the case of a test using the same thread for more
than one role (e.g. signaling, worker, network are all the same thread)
that an actual thread switch did not occur but it would have occurred
in the case of having dedicated threads. The 'total' count is the sum.
* RTC_DCHECK_BLOCK_COUNT_NO_MORE_THAN(x)
Example:
void MyClass::MyFunction() {
RTC_LOG_THREAD_BLOCK_COUNT();
thread_->Invoke<void>([this](){ DoStuff(); });
thread_->Invoke<void>([this](){ MoreStuff(); });
RTC_DCHECK_BLOCK_COUNT_NO_MORE_THAN(1);
}
When a function is known to have blocking calls and we want to not
regress from the currently known number of blocking calls, we can use
this macro to state that at a certain point in a function, below
where RTC_LOG_THREAD_BLOCK_COUNT() is called, there must have occurred
no more than |x| (total) blocking calls. If more occur, a DCHECK will
hit and print out what the actual number of calls was:
# Fatal error in: my_file.cc, line 5
# last system error: 60
# Check failed: blocked_call_count_printer.GetTotalBlockedCallCount() <= 1 (2 vs. 1)
Bug: webrtc:12649
Change-Id: Ibac4f85f00b89680601dba54a651eac95a0f45d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213782
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33632}
with bot using old version of gcc removed, this workaround is not needed.
Bug: webrtc:12481
Change-Id: Ib1bfb6260c7ff5688c39fa05e8a62225700b9f27
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213187
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33592}
This reverts commit 1e60490ddb11afecc796058802fbc80867d851d8.
Reason for revert: Downstream project has been fixed (127.0.0.1 is not PII)
Original change's description:
> Revert "Fix problem with ipv4 over ipv6 on Android"
>
> This reverts commit da2fd2a2b25ee4bd7b383424cb26d51fb6cc7716,
> as well as follow-up b7227a5a10f233cec04642f15a0233e7355bd340,
> "Fix handling of partial match for GetVpnUnderlyingAdapterType".
>
> Reason for revert: Breaks downstream test.
>
> First change's description:
> > Fix problem with ipv4 over ipv6 on Android
> >
> > This patch fixes a problem with using ipv4 over ipv6
> > addresses on Android. These addresses are discovered
> > using 'getifaddr' with interfaces called 'v4-wlan0' or
> > 'v4-rmnet' but the Android API does not report them.
> >
> > This leads to failure when BasicPortAllocator tries
> > to bind a socket to the ip-address, making the ipv4
> > address unusable.
> >
> > This solution does the following
> > 1) Insert BasicNetworkManager as NetworkBinderInterface
> > rather than AndroidNetworkManager.
> >
> > 2) When SocketServer calls BindSocketToNetwork,
> > BasicNetworkManager first lookup the interface name,
> > and then calls AndroidNetworkManager.
> >
> > 3) AndroidNetworkManager will then first try to bind
> > using the known ip-addresses, and if it can't find the network
> > it will instead match the interface names.
> >
> > The patch has been tested on real android devices, and works fine.
> > And everything is disabled by default, and is enabled by field trial.
> >
> > My plan is to rollout the feature, checking that it does not introduce
> > any problems, and if so, enabled for all.
> >
> > Bug: webrtc:10707
> > Change-Id: I7081ba43d4ce17077acfa5fbab44eda127ac3971
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211003
> > Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
> > Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33422}
>
> Second change's description:
> > Fix handling of partial match for GetVpnUnderlyingAdapterType
> >
> > This is a followup to https://webrtc-review.googlesource.com/c/src/+/211003
> > and fixes the problem pointed out by deadbeef@, thanks!
> >
> > Bug: webrtc:10707
> > Change-Id: I8dea842b25ba15416353ce4002356183087873c7
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211344
> > Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
> > Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33436}
>
> TBR=hta@webrtc.org,jonaso@webrtc.org
> NOTRY=True
>
> Bug: webrtc:10707
> Change-Id: Ib13127fbf087c7f34ca0ccc6ce1805706f01d19d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211740
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Taylor <deadbeef@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33453}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:10707
Change-Id: I0a11025c366c3127e2f57cd2cd2c33cc3877d1e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211862
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33460}
This reverts commit da2fd2a2b25ee4bd7b383424cb26d51fb6cc7716,
as well as follow-up b7227a5a10f233cec04642f15a0233e7355bd340,
"Fix handling of partial match for GetVpnUnderlyingAdapterType".
Reason for revert: Breaks downstream test.
First change's description:
> Fix problem with ipv4 over ipv6 on Android
>
> This patch fixes a problem with using ipv4 over ipv6
> addresses on Android. These addresses are discovered
> using 'getifaddr' with interfaces called 'v4-wlan0' or
> 'v4-rmnet' but the Android API does not report them.
>
> This leads to failure when BasicPortAllocator tries
> to bind a socket to the ip-address, making the ipv4
> address unusable.
>
> This solution does the following
> 1) Insert BasicNetworkManager as NetworkBinderInterface
> rather than AndroidNetworkManager.
>
> 2) When SocketServer calls BindSocketToNetwork,
> BasicNetworkManager first lookup the interface name,
> and then calls AndroidNetworkManager.
>
> 3) AndroidNetworkManager will then first try to bind
> using the known ip-addresses, and if it can't find the network
> it will instead match the interface names.
>
> The patch has been tested on real android devices, and works fine.
> And everything is disabled by default, and is enabled by field trial.
>
> My plan is to rollout the feature, checking that it does not introduce
> any problems, and if so, enabled for all.
>
> Bug: webrtc:10707
> Change-Id: I7081ba43d4ce17077acfa5fbab44eda127ac3971
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211003
> Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33422}
Second change's description:
> Fix handling of partial match for GetVpnUnderlyingAdapterType
>
> This is a followup to https://webrtc-review.googlesource.com/c/src/+/211003
> and fixes the problem pointed out by deadbeef@, thanks!
>
> Bug: webrtc:10707
> Change-Id: I8dea842b25ba15416353ce4002356183087873c7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211344
> Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33436}
TBR=hta@webrtc.org,jonaso@webrtc.org
NOTRY=True
Bug: webrtc:10707
Change-Id: Ib13127fbf087c7f34ca0ccc6ce1805706f01d19d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211740
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33453}
Removes use of AsyncInvoker, replaced with PendingTaskSafetyFlag. The
latter is extended to support creation on a different thread than
where it will be used, and to support stop and restart.
Bug: webrtc:12339
Change-Id: I28b6e09b1542f50037e842ef5fe3a47d15704b46
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211002
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33432}
This will allow us to write tests for what happens when large datagrams
are discarded.
Bug: webrtc:12495
Change-Id: I5c8e9fe55917967ea4604e1b3abe3c590c330ffa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211044
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33425}
This patch fixes a problem with using ipv4 over ipv6
addresses on Android. These addresses are discovered
using 'getifaddr' with interfaces called 'v4-wlan0' or
'v4-rmnet' but the Android API does not report them.
This leads to failure when BasicPortAllocator tries
to bind a socket to the ip-address, making the ipv4
address unusable.
This solution does the following
1) Insert BasicNetworkManager as NetworkBinderInterface
rather than AndroidNetworkManager.
2) When SocketServer calls BindSocketToNetwork,
BasicNetworkManager first lookup the interface name,
and then calls AndroidNetworkManager.
3) AndroidNetworkManager will then first try to bind
using the known ip-addresses, and if it can't find the network
it will instead match the interface names.
The patch has been tested on real android devices, and works fine.
And everything is disabled by default, and is enabled by field trial.
My plan is to rollout the feature, checking that it does not introduce
any problems, and if so, enabled for all.
Bug: webrtc:10707
Change-Id: I7081ba43d4ce17077acfa5fbab44eda127ac3971
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211003
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33422}
This reverts commit cd5127b11e04b7f49031b2412625c36e4a86c3da.
Reason for revert: Fuzzer build problems fixed.
Original change's description:
> Revert "Enable use of rtc::SystemTimeNanos() provided by Chromium"
>
> This reverts commit dfe19719e53abfd4d73722942445c5e1046b671b.
>
> Reason for revert: Breaks fuzzers in Chromium builds. See https://ci.chromium.org/ui/p/chromium/builders/try/linux-libfuzzer-asan-rel/685438/overview. I am reverting since this blocks the roll but I will be in touch for a fix.
>
> Original change's description:
> > Enable use of rtc::SystemTimeNanos() provided by Chromium
> >
> > This is the third CL out of three to enable overriding
> > of the function SystemTimeNanos() in rtc_base/system_time.cc
> >
> > When WebRTC is built as part of Chromium the rtc::SystemTimeNanos()
> > function provided by Chromium will be used. This is controlled
> > by the build argument rtc_exclude_system_time which directly
> > maps to the macro WEBRTC_EXCLUDE_SYSTEM_TIME.
> >
> > By doing this we are making sure that the WebRTC and Chromium
> > clocks are the same.
> >
> > Bug: chromium:516700
> > Change-Id: If7f749c4aadefb1cfc07ba4c7e3f45dc6c31118b
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208223
> > Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> > Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33337}
>
> TBR=kron@webrtc.org
>
> Bug: chromium:516700
> Change-Id: I9ecd1784a6c1cdac8bae07d34f7df20c62a21a95
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208740
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33340}
Bug: chromium:516700
Change-Id: I4cd68bac1cc4befdb46351f5d6fb2cf1ef5c3062
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208742
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33341}
This reverts commit dfe19719e53abfd4d73722942445c5e1046b671b.
Reason for revert: Breaks fuzzers in Chromium builds. See https://ci.chromium.org/ui/p/chromium/builders/try/linux-libfuzzer-asan-rel/685438/overview. I am reverting since this blocks the roll but I will be in touch for a fix.
Original change's description:
> Enable use of rtc::SystemTimeNanos() provided by Chromium
>
> This is the third CL out of three to enable overriding
> of the function SystemTimeNanos() in rtc_base/system_time.cc
>
> When WebRTC is built as part of Chromium the rtc::SystemTimeNanos()
> function provided by Chromium will be used. This is controlled
> by the build argument rtc_exclude_system_time which directly
> maps to the macro WEBRTC_EXCLUDE_SYSTEM_TIME.
>
> By doing this we are making sure that the WebRTC and Chromium
> clocks are the same.
>
> Bug: chromium:516700
> Change-Id: If7f749c4aadefb1cfc07ba4c7e3f45dc6c31118b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208223
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33337}
TBR=kron@webrtc.org
Bug: chromium:516700
Change-Id: I9ecd1784a6c1cdac8bae07d34f7df20c62a21a95
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208740
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33340}
This is the third CL out of three to enable overriding
of the function SystemTimeNanos() in rtc_base/system_time.cc
When WebRTC is built as part of Chromium the rtc::SystemTimeNanos()
function provided by Chromium will be used. This is controlled
by the build argument rtc_exclude_system_time which directly
maps to the macro WEBRTC_EXCLUDE_SYSTEM_TIME.
By doing this we are making sure that the WebRTC and Chromium
clocks are the same.
Bug: chromium:516700
Change-Id: If7f749c4aadefb1cfc07ba4c7e3f45dc6c31118b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208223
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33337}
SystemTimeNanos() will soon be replaced with another implementation
when built with Chromium. This will break the assumption of
SystemTimeNanos() being relative to the NTP epoch. To avoid breaking
any UWP apps, call the TimeHelper::Ticks() function directly, which
is synchronized with the NTP epoch during initialization.
Bug: chromium:516700
Change-Id: I4e50cb3f88d06e1385e73b1a9ded52956501dc1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208520
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33324}
This remove webrtc-specific macro that has no reason to be webrtc specific
ABSL_DEPRECATED takes a message parameter encouraging to write text how class or function is deprecated.
Bug: webrtc:12484
Change-Id: I89f1398f91dacadc37f7db469dcd985e3724e444
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208282
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33314}
Prepare for this function to be overridden when WebRTC is included
into other applications such as chromium. This will make it
possible to remove code that keeps track of the difference between
WebRTC and chromium time.
Bug: chromium:516700
Change-Id: I73133804f945cc439f9827ec68a8e67b96d8560f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204304
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33273}
The one remaining RecursiveCriticalSection likely needs a bit more
care.
Bug: webrtc:11567
Change-Id: Ie81085969197bed03ac8e2d269b58653b86095e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206468
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33206}
By requiring Release to be called with lock held. This is a bit of a
kludge, but I think this works, because all known users of this
deprecated class call Release either from OnWorkStop or
SignalWorkDone, and both are called with the lock already held.
Bug: webrtc:11567
Change-Id: Idf0007188e45a465aefcb8f13fea93a68930fe1c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204483
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33188}
