Without this patch, Valgrind's Memcheck was complaining that the test
for whether we should return -1 following the call to
WebRtcIsac_DecodeLb made a conditional branch or move based on the
value of numSamplesLB, which was uninitialized if WebRtcIsac_DecodeLb
failed.
However, as can be seen in the source, the control flow only depends
on the value of numSamplesLB if numDecodedBytesLB >= 0; i.e., if
WebRtcIsac_DecodeLb returned successfully, in which case numSamplesLB
is always initialized. The discrepancy is due to the fact that
Valgrind works on the generated machine code, which contains spurious
such dependencies. The generated code for this test:
if ((numDecodedBytesLB < 0) || (numDecodedBytesLB > lenEncodedLBBytes) ||
(numSamplesLB > MAX_FRAMESAMPLES)) {
looks like this:
95: 0f bf 45 d6 movswl -0x2a(%rbp),%eax
99: 3d c0 03 00 00 cmp $0x3c0,%eax
9e: 0f 8f 45 01 00 00 jg 1e9 <Decode+0x1e9>
a4: 44 89 f0 mov %r14d,%eax
a7: c1 e0 10 shl $0x10,%eax
aa: 0f 88 39 01 00 00 js 1e9 <Decode+0x1e9>
b0: 41 0f bf ce movswl %r14w,%ecx
b4: 89 8d 98 e1 ff ff mov %ecx,-0x1e68(%rbp)
ba: 41 0f bf c7 movswl %r15w,%eax
be: 39 c1 cmp %eax,%ecx
c0: 0f 8f 23 01 00 00 jg 1e9 <Decode+0x1e9>
Note how the compiler has seemingly ignored the C language's guarantee
that the arguments to || must be evaluated in left-to-right order, and
compares numSamplesLB (%eax) with MAX_FRAMESAMPLES (0x3c0, a.k.a. 960)
before the other two conditions! If the uninitialized value in
numSamplesLB happens to be greater than 960, we'll jump to
Decode+0x1e9 (where we'll return -1) without even looking at the other
two conditions. Has the compiler generated broken code?
Well, no. If numDecodedBytesLB is < 0 so that numSamplesLB is
uninitialized, we'll end up jumping to 1e9 whether that value is
greater than 960 or not; we'll just do it with different jump
instructions. This is entirely invisible as far as the C language is
concerned, but the dependency on the uninitialized value is visible at
the machine code level, which is why Memcheck complains.
This patch solves the problem by pragmatically initializing
numSamplesLB before the call even though it isn't necessary other than
for placating Memcheck.
BUG=4143
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36309004
Cr-Commit-Position: refs/heads/master@{#8492}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8492 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add max_bit_rate and max_payload_size_bytes to config structs.
- Fix support for 48 kHz sample rate.
- Fix iSAC-RED.
- Add method UpdateDecoderSampleRate().
- Update locking structure with a separate lock for local member
variables used by the encoder methods.
BUG=3926
COAUTHOR:kwiberg@webrtc.org
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41659004
Cr-Commit-Position: refs/heads/master@{#8204}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8204 4adac7df-926f-26a2-2b94-8c16560cd09d
NOTICE: Assembly offsets generation for audio processing will
not be ported to GN and the process of removing them is tracked
in https://code.google.com/p/webrtc/issues/detail?id=3580.
The GN files are based upon the GYP files as of r7009.
BUG=3441
TESTED=Passing builds with:
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 aec_debug_dump=true" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false aec_untrusted_delay_for_testing=true" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false prefer_fixed_point=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
I don't know how to setup the mips toolchain to test the following, but it's out of scope for the GN effort for now:
gn gen out/Default --args="build_with_chromium=false cpu_arch=\"mipsel\" mips_dsp_rev=0" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false cpu_arch=\"mipsel\" mips_dsp_rev=1" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false cpu_arch=\"mipsel\" mips_dsp_rev=2" && 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=andrew@webrtc.org, brettw@chromium.org
Review URL: https://webrtc-codereview.appspot.com/15999004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7012 4adac7df-926f-26a2-2b94-8c16560cd09d
---
Fixes for re-enabling more MSVC level 4 warnings: webrtc/ edition
This contains fixes for the following sorts of issues:
* Possibly-uninitialized local variable
* Signedness mismatch
* Assignment inside conditional
This also contains a small number of other cleanups to nearby code. In
particular several warning-disables for MSVC are removed because they don't seem
to be necessary (either that warning is not enabled or the code does not trigger
it).
BUG=crbug.com/81439
TEST=none
R=henrika@webrtc.org, pkasting@chromium.org
Review URL: https://webrtc-codereview.appspot.com/18769004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6667 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL brought to you by:
$ for d in $(for f in $(git ls-files '*gyp' '*gypi'); do dirname $f; done|sort|uniq|grep -v '^\.$'); do echo -e "\n# These are for the common case of adding or renaming files. If you're doing\n# structural changes, please get a review from a reviewer in this file.\nper-file *.gyp=*\nper-file *.gypi=*" >> $d/OWNERS; done
$ for d in $(for f in $(git ls-files '*gyp' '*gypi'); do dirname $f; done|sort|uniq|grep -v '^\.$'); do git add $d/OWNERS; done
(and then removed the talk/ impact)
R=niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11969004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5903 4adac7df-926f-26a2-2b94-8c16560cd09d
Instead have ProcessStream transparently handle changes to the stream
audio parameters (sample rate and channels). This removes two locks
per 10 ms ProcessStream call taken by VoiceEngine (four total with the
audio level indicator.)
Also, prepare future improvements by having the splitting filter take
a length parameter. This will allow it to work at different sample
rates. Remove the useless splitting_filter wrapper.
TESTED=voe_cmd_test with audio processing enabled and switching between
codecs; unit tests.
R=aluebs@webrtc.org, bjornv@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/3949004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5346 4adac7df-926f-26a2-2b94-8c16560cd09d
Test:
-manual test with voe_cmd_test.
-manual test with RTPEncode & NetEqRTPPlay.
-manual test with simpleKenny.
-Bit-exact test of iSAC-swb and iSAC-wb with head revision of trunk. The bit-exactness is confirmed on all files generated by running webrtc/modules/audio_coding/codecs/isac/main/test/QA/runiSACLongtest.txt
Review URL: https://webrtc-codereview.appspot.com/937025
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3226 4adac7df-926f-26a2-2b94-8c16560cd09d
