Indirect-leak in media::PipelineImpl::PipelineImpl |
||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4815863527768064 Fuzzer: libFuzzer_mediasource_WEBM_VP9_pipeline_integration_fuzzer Fuzz target binary: mediasource_WEBM_VP9_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Indirect-leak Crash Address: Crash State: media::PipelineImpl::PipelineImpl media::PipelineIntegrationTestBase::PipelineIntegrationTestBase media::MediaSourcePipelineIntegrationFuzzerTest::MediaSourcePipelineIntegrationF Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4815863527768064 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally. 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.
,
Jan 1
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Jan 1
Automatically adding ccs based on OWNERS file / target commit history. If this is incorrect, please add ClusterFuzz-Wrong label.
,
Jan 7
Doesn't seem to like the new media log.
,
Jan 8
,
Jan 8
It's leaking the RendererWrapper: https://chromium.googlesource.com/chromium/src/+/9fcb31bbbfa1b710a9abd6cf53815a1407665a98/media/base/pipeline_impl.cc#1006 So I don't think this has anything to do with MediaLog. Could this be related to the Stop() refactoring change?
,
Jan 8
Hmm, maybe, but those changes are mostly in WMPI. Looking at ~PITB we Stop() the pipeline and then call pipeline_.reset() and then RunUntilIdle(), so it should destruct it correctly... Maybe we should be using scoped_task_environment_.RunUntilIdle() in destructor instead?
,
Jan 9
k, I'll take a look at that.
,
Jan 9
The current memory leak is not reliably reproducible :( Looking at the code, I agree calling scoped_task_environment_.RunUntilIdle() seems better without harm. But I don't feel that's the root cause of the memory leak. Our media thread task runner is GetMainThreadTaskRunner() [0], which is the same as what will be returned by base::ThreadTaskRunnerHandle::Get() [1]. RunLoop().RunUntilIdle() should at least run ThreadTaskRunnerHandle queue until it's empty, which should delete RendererWrapper. I'll still update the test to use scoped_task_environment_.RunUntilIdle(). But other than that I don't see anything I can do. I'll probably just wait for the bot the check whether this can be reproducible again or not. [0] https://cs.chromium.org/chromium/src/base/test/scoped_task_environment.cc?sq=package:chromium&g=0&l=436 [1] https://cs.chromium.org/chromium/src/base/test/scoped_task_environment.cc?sq=package:chromium&g=0&l=334 [2] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/threading_and_tasks.md#testing |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ClusterFuzz
, Jan 1