The current code got added in libjingle r103; I don't see a good reason for it.
Things still build with plain old assert.h.
The custom assert was wrong: __debugbreak() is documented to return void,
so doing `cond ? true : __debugbreak()` shouldn't build (and it doesn't in
clang-cl). It's possible to make it build by writing
`cond ? true : (__debugbreak(), true)`, but just using the regular header
seems like a much better fix.
BUG=chromium:82385
Review URL: https://webrtc-codereview.appspot.com/19139004/
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7007 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
Also add more from common.gypi to webrtc.gni.
These GN configs are based on GYP files in r6997.
BUG=3441
TEST=Trybots and local compile using:
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
Passed compile from a Chromium checkout with src/third_party/webrtc linked to the webrtc/ dir of a checkout with this patch applied.
R=brettw@chromium.org, glaznev@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/18709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6999 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
This should save several gigabytes of traffic and disk space.
On Linux this is about 2.6 GB:
346M src/chrome/tools/test/reference_build
340M src/native_client
170M src/third_party/ffmpeg
1.5G src/third_party/WebKit
196M src/v8
BUG=2863
TESTED=Removed the directories locally, ran a sync and verified they didn't reappear (or fail because of platform-specific ones).
R=iannucci@chromium.org, niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6984 4adac7df-926f-26a2-2b94-8c16560cd09d
Adressing clear races between the test thread and capturer thread shown
as heap-use-after-free in vpx_codec_destroy in
WebRtcVideoMediaChannelTest.SetSend (way later in the rest run).
When capturing a frame the test copied it to a separate frame that would
then be read by the test without synchronization, if the test didn't
manage to examine the frame in between captures the adapted frame would
be overwritten by the following frame during accesses to it.
The actual races are suppressed by race:webrtc/base/messagequeue.cc and
race:webrtc/base/thread.cc. These fixes reduce the suppression count
locally from around 3000 to 30 for VideoAdapterTest.*.
Also removing tsan suppressions for talk/base as it's been moved to
webrtc/base.
R=tommi@webrtc.org
BUG=3671
Review URL: https://webrtc-codereview.appspot.com/22169004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6979 4adac7df-926f-26a2-2b94-8c16560cd09d
Now that WebRTC has rolled the chromium_revision past
http://crrev.com/284372 in r6784, clang has become the
default compiler. Since WebRTC standalone code doesn't
yet compile the Chromium Clang plugins enabled, this CL
disables them for the parts of the code that doesn't yet pass
compilation with them enabled.
The buildbots are using Goma which is not yet switched
over to Clang by default. That's why they're not red yet.
BUG=163
TEST=Passing compile locally on Linux using:
gn gen out/Debug --args="build_with_chromium=false is_debug=true" && ninja
-C out/Debug
gn gen out/Release --args="build_with_chromium=false is_debug=false" && ninja
-C out/Release
gn gen out/Default --args="build_with_chromium=false os=\"android\" cpu_arch=\"arm\" arm_version=7" && ninja -C out/Default
R=brettw@chromium.org
Review URL: https://webrtc-codereview.appspot.com/16279004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6966 4adac7df-926f-26a2-2b94-8c16560cd09d
