We do not allow blocking call from the worker thread, but on Android the worker thread may stop/join a SignalThread, which hits the assert.
AssertBlockingIsAllowedOnCurrentThread is used to make sure a thread does not do Invoke, so check that in Thread::Join does not seem to add much value.
BUG=3857
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7308 4adac7df-926f-26a2-2b94-8c16560cd09d
Previously if thread A->Send is called on thread B, B->ReceiveSends will be called, which enables an arbitrary thread to invoke calls on B while B is wait for A->Send to return. This caused mutliple problems like issue 3559, 3579.
The fix is to limit B->ReceiveSends to only process requests from A.
Also disallow the worker thread invoking other threads.
BUG=3559
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15089004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7290 4adac7df-926f-26a2-2b94-8c16560cd09d
The synchronization access is unnecessary for rtc::Thread::WrapCurrent (called from JingleThreadWrapper) since JingleThreadWrapper never calls rtc::Thread::Stop or rtc::Thread::Join. Failing to get the access caused crashes in Chrome since rtc::Thread::Current will be NULL when rtc::Thread::WrapCurrent fails.
rtc::ThreadManager::WrapCurrentThread still requires the synchronization access, since I am not sure if the callers (e.g. the plugin) depends on it.
BUG=crbug/413853
R=juberti@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30429004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7224 4adac7df-926f-26a2-2b94-8c16560cd09d
1) return the first global temporary and non-deprecrated ones.
2) if #1 not available, return global one.
3) if #2 not available, use ULA ipv6 as last resort.
ULA stands for unique local address. They are only useful in a private
WebRTC deployment. More detail: http://en.wikipedia.org/wiki/Unique_local_address
BUG=3808
At this point, rule #3 actually won't happen at current
implementation. The reason being that ULA address starting with 0xfc 0r 0xfd will be grouped into its own Network. The result of that is WebRTC will have one extra Network to generate candidates but the lack of rule #3 shouldn't prevent turning on IPv6 since ULA should only be tried in a close deployment anyway.
R=jiayl@webrtc.org
Committed: https://code.google.com/p/webrtc/source/detail?r=7200
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7201 4adac7df-926f-26a2-2b94-8c16560cd09d
1) return the first global temporary and non-deprecrated ones.
2) if #1 not available, return global one.
3) if #2 not available, use ULA ipv6 as last resort.
ULA stands for unique local address. They are only useful in a private
WebRTC deployment. More detail: http://en.wikipedia.org/wiki/Unique_local_address
BUG=3808
At this point, rule #3 actually won't happen at current
implementation. The reason being that ULA address starting with 0xfc 0r 0xfd will be grouped into its own Network. The result of that is WebRTC will have one extra Network to generate candidates but the lack of rule #3 shouldn't prevent turning on IPv6 since ULA should only be tried in a close deployment anyway.
R=jiayl@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7200 4adac7df-926f-26a2-2b94-8c16560cd09d
rtc_base drags in a bunch of unwieldly dependencies (e.g. nss and
json) not required for standalone webrtc (aka rtc/media). The root of
the problem appears to be that MessageQueue depends on a socket server.
(And since common.h -> logging.h -> thread.h -> messagequeue.h, this
dependency spreads quickly.)
This starts a new target for a "purified" subset of rtc_base. It adds
the files which are already being used, replacing the use of common.h
with checks.h. desktop_capture is a lost cause, and retains its
dependency on the full rtc_base.
The hope is that as additional components are desired they will be
cleaned and added to rtc_base_approved.
BUG=3806
R=andresp@webrtc.org, henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7188 4adac7df-926f-26a2-2b94-8c16560cd09d
This requires two fixes:
1. Use DCHECK instead of assert in ThreadChecker's unittest.
2. Activate DCHECK when DCHECK_ALWAYS_ON in enabled.
Both these modifications are in line with Chromium's implementation.
The ThreadChecker unittest was changed to use assert instead of DCHECK
on the initial import (since WebRTC did not have a DCHECK back then).
BUG=3803
TEST=local out/{Debug,Release}/rtc_unittests built with and without DCHECK_ALWAYS_ON
R=andrew@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24569004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7178 4adac7df-926f-26a2-2b94-8c16560cd09d
In r7140 the webrtc_base target was renamed to rtc_base. This
breaks our FYI bots for rolling WebRTC in Chromium's DEPS.
By re-adding a None target named webrtc_base, this transition
should be smoother.
TBR=henrikg@webrtc.org,
TESTED=Passed build/gyp_chromium on a Chromium checkout with src/third_party/webrtc replaced by a mount like this:
cd /path/to/chromium/src
sudo mount --bind /path/to/webrtc/trunk/webrtc third_party/webrtc
Review URL: https://webrtc-codereview.appspot.com/23589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7150 4adac7df-926f-26a2-2b94-8c16560cd09d
logging.h apparently drags in a lot of undesirable dependencies. It was
only required for the trivial LogMessageVoidify; simply add an
identical FatalMessageVoidify instead.
Keep the include in a Chromium build to still have the override
mechanism use Chromium's macros.
Bonus: Add the missing DCHECK_GT (noticed by bercic).
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/17259004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7031 4adac7df-926f-26a2-2b94-8c16560cd09d
Update the webrtc/base/BUILD.gn file to reflect
webrtc/base/base.gyp changes between r6438 and r7011.
BUG=3441
TESTED= Trybots + compilation with a standalone WebRTC checkout:
gn gen out/Default --args="build_with_chromium=false" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false is_debug=true" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false os=\"android\" cpu_arch=\"arm\" is_clang=false" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false os=\"android\" cpu_arch=\"arm\" arm_version=7 is_clang=false" && ninja -C out/Default
Compilation of Chromium's 'all' target with src/third_party/webrtc
symlinked to the WebRTC checkout with this CL applied, both
with the default GN settings and using
--args="is_debug=false os=\"android\" cpu_arch=\"arm\""
R=brettw@chromium.org
Review URL: https://webrtc-codereview.appspot.com/13359004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7022 4adac7df-926f-26a2-2b94-8c16560cd09d
As documented, the use of overrides/webrtc/base/logging.h in a Chromium
build reuslts in redefined macro errors. Fortunately, Chromium's macros
can be used as drop-in replacements for the standalone versions.
TBR=henrike
Review URL: https://webrtc-codereview.appspot.com/17239004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7004 4adac7df-926f-26a2-2b94-8c16560cd09d
Replace FATAL_ERROR_IF with the more familiar (to Chromium developers)
CHECK and DCHECK. The full Chromium implementation is fairly elaborate
but I copied enough to get us most of the benefits. I believe the main
missing component is a more advanced stack dump. For this bit I relied
on the V8 implementation.
There are a few minor modifications from the Chromium original:
- The FatalMessage class is specialized for logging fatal error
messages and aborting. Chromium uses the general LogMessage class,
which we could consider moving towards in the future.
- NOTIMPLEMENTED() and NOTREACHED() have been removed, partly because
I don't want to rely on our logging.h until base/ and system_wrappers/
are consolidated.
- FATAL() replaces LOG(FATAL).
Minor modifications from V8's stack dump:
- If parsing of a stack trace symbol fails, just print the unparsed
symbol. (I noticed this happened on Mac.)
- Use __GLIBCXX__ and __UCLIBC__. This is from examining the backtrace
use in Chromium.
UNREACHABLE() has been removed because its behavior is different than
Chromium's NOTREACHED(), which is bound to cause confusion. The few uses
were replaced with FATAL(), matching the previous behavior.
Add a NO_RETURN macro, allowing us to remove unreachable return
statements following a CHECK/FATAL.
TESTED=the addition of dummy CHECK, DCHECK, CHECK_EQ and FATAL did the
did the right things. Stack traces work on Mac, but I don't get symbols
on Linux.
R=henrik.lundin@webrtc.org, kwiberg@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22449004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7003 4adac7df-926f-26a2-2b94-8c16560cd09d
