New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 802245 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Timeout in neteq_signal_fuzzer

Project Member Reported by ClusterFuzz, Jan 16 2018

Issue description

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

Fuzzer: libFuzzer_neteq_signal_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  neteq_signal_fuzzer
  
Sanitizer: address (ASAN)

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

Issue filed automatically.

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

Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.
 
Cc: hlundin@chromium.org brajkumar@chromium.org
Components: Blink>WebRTC
Labels: Test-Predator-Wrong CF-NeedsTriage
Unable to find actual suspect through code search and also no regressed revision range is seen in the detailed report, hence adding appropriate label and marking it as untriaged.

Thanks!
Project Member

Comment 2 by ClusterFuzz, Jan 18 2018

Labels: OS-Mac

Comment 3 by guidou@chromium.org, Jan 18 2018

Components: -Blink>WebRTC Blink>WebRTC>Audio

Comment 4 by ossu@chromium.org, Jan 18 2018

Owner: hlundin@chromium.org
Status: Assigned (was: Untriaged)
Could you PTAL. It looks like it's mainly just running WebRtcPcm16b_Encode, which is fairly benign. I guess if the provided length was very large, it could run for a very long time.
[Re-triage] Henrik, what's the status here? No work done yet I presume? It's a P1, so it should either get attention or prio lowered.
Status: Started (was: Assigned)
A fix is in the pipeline.
Project Member

Comment 7 by bugdroid1@chromium.org, Feb 26 2018

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

commit 2a6d8642647e7794c9040f3d2e0b3d223d6825e9
Author: Henrik Lundin <henrik.lundin@webrtc.org>
Date: Mon Feb 26 10:42:30 2018

neteq_signal_fuzzer: limit the fuzzer input size to avoid timeout

The length of the fuzzer input can sometimes be really long (more than
600000 bytes), and this take a very long time to execute. Typically,
the fuzzer times out instead. This change limits the used length of
the fuzzer to 100000 bytes.

NOTRY=TRUE

Bug:  chromium:802245 
Change-Id: Ibe02b6de932d900408f870d9ba440b7b8e08dc0e
Reviewed-on: https://webrtc-review.googlesource.com/57180
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Alex Loiko <aleloi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22181}
[modify] https://crrev.com/2a6d8642647e7794c9040f3d2e0b3d223d6825e9/test/fuzzers/neteq_signal_fuzzer.cc

Status: Fixed (was: Started)
I believe this should be fixed with the above commit.

Sign in to add a comment