Issue metadata
Sign in to add a comment
|
Use of an invalid mutex in pthread_mutex_unlock |
||||||||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5467756974833664 Fuzzer: phoglund_webrtc_peerconnection Job Type: linux_tsan_chrome_mp Platform Id: linux Crash Type: Use of an invalid mutex Crash Address: Crash State: pthread_mutex_unlock rtc::CritScope::~CritScope webrtc::voe::Channel::ProcessAndEncodeAudioOnTaskQueue Sanitizer: thread (TSAN) Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=468550:468553 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5467756974833664 Additional requirements: Requires HTTP Issue filed automatically. See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
,
May 4 2017
,
May 4 2017
This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 4 2017
,
May 4 2017
I'm having a look at it but have not been able to pin it down yet.
,
May 4 2017
Have been trying (and succeeding) to replicate this locally. Looks like it appeared with my CL changing WebRTC encoder management[1]. Running a Chrome built with WebRTC ToT, I can no longer reproduce it. Most likely fixed by henrika@'s CL[2]. I'll reassign to you, henrika@ to keep an eye on over the next few days. Once the next WebRTC is imported into Chromium, the problem should go away by itself. [1] https://codereview.webrtc.org/2705093002 [2] https://codereview.webrtc.org/2861583005
,
May 5 2017
Makes sense. Can we do anything else?
,
May 5 2017
Nope. Looks like your changes have made it in now, so we should be all set. I've tried to re-run the task to get an all-clear from the bot, but it seems unable to reproduce it even with a version it previously could. I expect we'll have to wait for it to figure this out on its own.
,
May 5 2017
Should we not mark is as fixed then? I am not sure what to track otherwise actually.
,
May 5 2017
We probably should. I was hoping ClusterFuzz would do that for us, but that may take too long considering this is a high prio bug.
,
May 5 2017
,
May 5 2017
,
May 8 2017
ClusterFuzz has detected this issue as fixed in range 469194:469222. Detailed report: https://clusterfuzz.com/testcase?key=5467756974833664 Fuzzer: phoglund_webrtc_peerconnection Job Type: linux_tsan_chrome_mp Platform Id: linux Crash Type: Use of an invalid mutex Crash Address: Crash State: pthread_mutex_unlock rtc::CritScope::~CritScope webrtc::voe::Channel::ProcessAndEncodeAudioOnTaskQueue Sanitizer: thread (TSAN) Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=468550:468553 Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=469194:469222 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5467756974833664 Additional requirements: Requires HTTP See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
May 8 2017
,
May 18 2017
,
Aug 11 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by och...@chromium.org
, May 3 2017Owner: ossu@chromium.org
Status: Assigned (was: Untriaged)