Predator and CL could not provide any possible suspects.

Using Code Search for the file, "aec_core.cc" and observed there was some recent changes for the below file.

Suspect CL: https://webrtc.googlesource.com/src.git/+/bb547203bfebcc478b263c4e9ca173c6fd5a0c5d

mbonadei@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Hi, my CL just moved the whole codebase up one level in September. I think the regression is not caused by that CL.

Adding peah@ since he is an owner of audio_processing. Per, can you assign it to the right person?

Thanks!

I know why this happens. It has the same root cause as https://bugs.chromium.org/p/chromium/issues/detail?id=803810. I have a WebRTC CL in review to fix it. https://webrtc-review.googlesource.com/c/src/+/41282

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/d2b5b1f5bae94c24cc279fe198ff28236821f1ac

commit d2b5b1f5bae94c24cc279fe198ff28236821f1ac
Author: Alex Loiko <aleloi@webrtc.org>
Date: Wed Jan 24 14:26:28 2018

Division by zero in NoiseSuppression.

This change handles a special case in NoiseSuppression. The special
case was found by the AudioProcessing fuzzer.

A const copy of the capture audio stream is sent to
NoiseSuppression::AnalyzeCaptureAudio. Then audio undergoes processing
by e.g. the echo canceller. Then it's processed by
NoiseSuppression::ProcessCaptureAudio.

The special case is when the following conditions are all satisfied:

* All stream samples are constantly zero in the call to
  AnalyzeCaptureAudio

* a processing component modifies it to be nonzero before the call to
  ProcessCaptureAudio

* The array NoiseSuppressionC::magnPrevAnalyze is filled with
  zeros. This holds after initialization.

In this case, there is a division by zero in WebRtcNs_ProcessCore. The
resulting NaN values pollute the output signal. They are only detected
several submodules later in the process chain. The NaN values cause
the EchoDetector to crash in debug mode.

There is special handling of the case when the signal is constant zero
in ProcessCore. This change avoids zero division by handling this
issue the same way.

Bug:  chromium:803810   chromium:804634 
Change-Id: I6d698dd0cd27e6d550b42085124300ce58533125
Reviewed-on: https://webrtc-review.googlesource.com/41282
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21745}
[modify] https://crrev.com/d2b5b1f5bae94c24cc279fe198ff28236821f1ac/modules/audio_processing/ns/ns_core.c
[modify] https://crrev.com/d2b5b1f5bae94c24cc279fe198ff28236821f1ac/modules/audio_processing/ns/ns_core.h

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/e994058eb1397ad18523067408ebeb9117e25a25

commit e994058eb1397ad18523067408ebeb9117e25a25
Author: Alex Loiko <aleloi@webrtc.org>
Date: Thu Jan 25 13:30:04 2018

NaNs in Echo Canceller.

A coherence vector cohxd is computed in
WebRtcAec_ComputeCoherence. The coherence values should theoretically
be 0 <= x <= 1. Due to the way they are computed that is not always
the case.

The coherence values are used to update an error signal
estimate hNl in webrtc::EchoSuppression. 'hNl[i]' should contain an
error magnitude for frequency 'i'.

The error magnitudes are used as a basis for exponentiation. If a
magnitude is negative, the result is NaN.

The NaNs will then spread to the output signal.

This change caps the hNl values at 0. I considered capping the
coherence values at 1. The coherence values are calculated differently
for MIPS, NEON and SSE. Therefore it's simpler to cap the hNl values
instead.

The issue was found by the AudioProcessing fuzzer.

Bug:  chromium:804634 
Change-Id: I8ebaa441d77c3f79d9c194a850cb2b9eed1c2024
Reviewed-on: https://webrtc-review.googlesource.com/43740
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21761}
[modify] https://crrev.com/e994058eb1397ad18523067408ebeb9117e25a25/modules/audio_processing/aec/aec_core.cc

ClusterFuzz has detected this issue as fixed in range 532187:532200.

Detailed report: https://clusterfuzz.com/testcase?key=5361923339321344

Fuzzer: libFuzzer_audio_processing_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  denominator >= 0 in aec_core.cc
  webrtc::UpdateLogRatioMetric
  webrtc::UpdateMetrics
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=529641:529651
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=532187:532200

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5361923339321344

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.