A DCHECK added in a recent bugfix, which asserted that a signed 64->32
bit cast did not overflow, has been found to not always pass. We fix
this by saturating.
BUG=chromium:693868
Review-Url: https://codereview.webrtc.org/2746903002
Cr-Commit-Position: refs/heads/master@{#17209}
In an attempt to help Kenny locate the evil Dr. Deo.
BUG=webrtc:7307
Review-Url: https://codereview.webrtc.org/2732193006
Cr-Commit-Position: refs/heads/master@{#17135}
A fuzzer run caused the operands of this multiplication to be 512 and
5000000, resulting in a product about 20% too large for int32_t. So
change this from a 16x32->32 to a 16x32->64 multiplication. Since we
right shift by 2 at the end, the end result will still fit in int32_t.
I also had to fix a few follow-on add/sub overflows found by the same
fuzzer input once the multiplication was fixed. I chose to saturate
these, since it wasn't just an intermediate value that overflowed.
BUG=chromium:693868
Review-Url: https://codereview.webrtc.org/2729573002
Cr-Commit-Position: refs/heads/master@{#17003}
We read past the end of the initialized part of the buffer, seemingly
on purpose (no one knows the details of this code anymore). The right
thing to do is probably to zero that part of the buffer.
(The *right* right thing to would be to rewrite this so that it was
easier to see what data was supposed to be where when, but
priorities...)
BUG=chromium:683040
Review-Url: https://codereview.webrtc.org/2659383002
Cr-Commit-Position: refs/heads/master@{#16365}
A left shift by 10 was assumed to never overflow, since "[s]imulation
of the 25 files shows that maximum value in the vector gain_lo_hiQ17[]
is 441344, which means that it is log2((2^31)/441344) = 12.2 shifting
bits from saturation." However, a fuzzer test succeeded in provoking
an overflow, which we ignore in this CL on the theory that only
"abnormal" inputs cause overflow.
Also had to replace a "foo << 1" with "foo * (1 << 1)" in
WEBRTC_SPL_MUL_16_32_RSFT15 because foo could be negative; this
problem showed up as soon as I'd asked UBSan to ignore the overflow
discussed above.
BUG=chromium:615819
Review-Url: https://codereview.webrtc.org/2314413002
Cr-Commit-Position: refs/heads/master@{#14162}
We hit a fuzzer bug that caused numDecodedBytesLB + numDecodedBytesUB
> lenEncodedBytes, which is obviously bogus. Check for that, and for
the case whhere the UB decoder itself realized that something was
wrong. (The code already makes the corresponding check for the LB
decoder.)
BUG=chromium:637899
Review-Url: https://codereview.webrtc.org/2315693002
Cr-Commit-Position: refs/heads/master@{#14091}
We have RTC_CHECK and RTC_DCHECK for C now, so we should use it. It's
one fewer difference between our C and C++ code.
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/2274083002
Cr-Commit-Position: refs/heads/master@{#13930}
This gets rid of the complex & icky state where the sample rate is not
yet determined.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2020353003
Cr-Commit-Position: refs/heads/master@{#13011}
This will let NetEq (and the factory, and every layer in between) keep
track of just the decoder, instead of decoder and sample rate.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2024633002
Cr-Commit-Position: refs/heads/master@{#12968}
I've settled on replacing x << n with x * (1 << n); this gets rid of
the "left shift of negative value" warning, but will still trigger
undefined behavior if the multiplication overflows. It also still
looks like a left shift, which is good for the readability of the
fixed-point code.
(The compiler is smart enough to recognize that the
multiplication+shift is just a shift, for both variable and constant
shift amounts, so the generated code should not change.)
BUG=chromium:603491
Review-Url: https://codereview.webrtc.org/1989803002
Cr-Commit-Position: refs/heads/master@{#12845}
Chrome does not detect NEON instruction set at runtime in WebRTC code starting
with M50, which is now in Stable. Remove support for runtime detection for
simplicity.
The only remaining piece of Chrome that will continue to depend on runtime
detection is /net, where devices with _broken_ neon support are also detected,
and it is not configurable via GYP/GN.
BUG=522035
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/1955413003
Cr-Commit-Position: refs/heads/master@{#12778}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
Any file that uses the RTC_DISALLOW_* macros should #include
"webrtc/base/constructormagic.h", but a shocking number of them don't.
This causes trouble when we try to wean files off of #including
scoped_ptr.h, since a bunch of files get their constructormagic macros
only from there.
Rather than fixing these errors one by one as they turn up, this CL
simply ensures that every file in the WebRTC tree that uses the
RTC_DISALLOW_* macros #includes "webrtc/base/constructormagic.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1917043005
Cr-Commit-Position: refs/heads/master@{#12509}
Remove the deprecated EncodeInternal interface from AudioEncoder
Also hid MaxEncodedBytes by making it private. It will get removed as soon as subclasses have had time to remove their overrides.
BUG=webrtc:5591
Review URL: https://codereview.webrtc.org/1881003003
Cr-Commit-Position: refs/heads/master@{#12409}
Reason for revert:
Broke import. Implementations of the old interface still exists somewhere.
Original issue's description:
> Remove the deprecated EncodeInternal interface from AudioEncoder
>
> Also hid MaxEncodedBytes by making it private. It will get removed as soon as subclasses have had time to remove their overrides.
>
> BUG=webrtc:5591
>
> Committed: https://crrev.com/5222d315dbea8f3563c100cc9f2451907f70b05f
> Cr-Commit-Position: refs/heads/master@{#12329}
TBR=kwiberg@webrtc.org,solenberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5591
Review URL: https://codereview.webrtc.org/1883543002
Cr-Commit-Position: refs/heads/master@{#12330}
Also hid MaxEncodedBytes by making it private. It will get removed as soon as subclasses have had time to remove their overrides.
BUG=webrtc:5591
Review URL: https://codereview.webrtc.org/1864993002
Cr-Commit-Position: refs/heads/master@{#12329}
Now that the Rent-A-Codec no longer owns the encoders and decoders it
produces, they may outlive it. It's thus no longer correct for the
Rent-A-Codec to own the bandwidth estimation state; all of the
involved objects need to share ownership.
BUG=webrtc:5028
Review URL: https://codereview.webrtc.org/1821513003
Cr-Commit-Position: refs/heads/master@{#12159}
WebRtcIsacfix_PitchFilterCore requires indW32 >= PITCH_FRACORDER - 2;
otherwise, it will read from entries of ubufQQ that haven't been
written yet. (The problem of indW32 being too small has only been seen
in fuzzer tests, not in real life.)
BUG=chromium:581901
Review URL: https://codereview.webrtc.org/1811453002
Cr-Commit-Position: refs/heads/master@{#12047}
Renamed the new variant of EncodeInternal to EncodeImpl, so that
subclasses implementing one of the EncodeInternal don't need to
explicitly contain 'using AudioEncoder::EncodeInternal' to avoid their
implementation hiding the other variant of EncodeInternal. This causes
a warning (treated as an error) when building using GCC.
Review URL: https://codereview.webrtc.org/1764583003
Cr-Commit-Position: refs/heads/master@{#11868}
For backwards compatibility, I've added kept the old interface to
Encode() and EncodeInternal and created default implementations of both
variants of EncodeInternal(), each calling the other. At least one of
the variants must be implemented in a subclass or we'll run out of stack
and explode. Would be nice if we could catch that before runtime. :/
The new interface to EncodeInternal() is protected, since it should
never be called from the outside.
Was unable to mark the old EncodeInternal() as RTC_DEPRECATED, since the
default implementaion of the new variant needs to call it to work around
old implementations. The old Encode() variant is deprecated, at least.
Added a test for backwards compatibility in audio_encoder_unittest.cc.
For the added test I broke out MockEncodeHelper from
audio_encoder_copy_red_unittest.cc and renamed it MockAudioEncoderHelper.
Review URL: https://codereview.webrtc.org/1725143003
Cr-Commit-Position: refs/heads/master@{#11823}
By doing an unsigned instead of a signed addition, we get the exact
same machine code (in non-UBSan builds), but no longer trigger
undefined behavior since unsigned overflow is defined behavior.
BUG=webrtc:5485
Review URL: https://codereview.webrtc.org/1734883003
Cr-Commit-Position: refs/heads/master@{#11776}
Previously, we relied on the encoded stream to come to an end before
the end of the buffer. This is a bad idea, since it is possible to
craft a stream that fills the buffer while decoding to less than the
expected amount of data; without the new checks introduced here, this
causes the decoder to read past the end of the input buffer.
BUG=chromium:582471, chromium:587852
Review URL: https://codereview.webrtc.org/1721593004
Cr-Commit-Position: refs/heads/master@{#11734}
Visual Studio 2015 balks at the implicit truncation of values. Easily fixed with an explicit cast.
Fixed redefinition of CLOCKS_PER_SEC when using Visual Studio 2015 and the Windows 10 SDK. CLOCKS_PER_SEC is also defined in "<WIN10 SDK DIR>\include\10.0.10240.0\ucrt\time.h" and also has the value of 1000
Hiding snprintf definition if building with Visual Studio 2015
Fixed C4573 compiler complaint in audio_processing_impl_locking_unittest.cc.
BUG=webrtc:5183
Review URL: https://codereview.webrtc.org/1412653006
Cr-Commit-Position: refs/heads/master@{#11434}
* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in tests). Since channels will be changing to size_t, negative values will be illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks
All this was found in the course of constructing https://codereview.webrtc.org/1316523002/ , and is being landed separately first.
BUG=none
TEST=none
Review URL: https://codereview.webrtc.org/1534193008
Cr-Commit-Position: refs/heads/master@{#11191}
Some toolchains (in this case referring to a g++ 4.9, or "arm-linux-
androideabi-g++ (GCC) 4.9 20140827 (prerelease)" according to my
--version, from the Android NDK r10e-rc4 and potentially with custom
patches; others may be affected as well) fail to prove that myVec in
WebRtcIsac_CorrelateInterVec is never used uninitialized. This is likely
due to the compiler thinking the assignment in line 468 might not
happen. Changing the loop condition in line 466 to rowCntr <
SOME_CONSTANT also helps, suggesting that the compiler can't infer that
there are only 2 values interVecDim can have at that point, and neither
of them are 0. Of course, this is not an acceptable fix, as it changes
behaviour.
This seems to be a compiler bug, or at least an issue with its
heuristics. However, we can't really change toolchains at the moment,
and ultimately this change improves support for certain older compilers.
BUG=
Review URL: https://codereview.webrtc.org/1406423004
Cr-Commit-Position: refs/heads/master@{#10337}
