Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/15433e9d60bdd2135f5df64a073cfd74b95243ac (Add Kiss FFT to RNNoise).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

Probably not that CL, no. I'll take a look at this tomorrow.

Please note that https://chromium.googlesource.com/chromium/src/+/15433e9d60bdd2135f5df64a073cfd74b95243ac (Add Kiss FFT to RNNoise) has no build targets (yet) because it imports 3pp code as is. Work in progress with https://chromium-review.googlesource.com/c/chromium/src/+/983557 (RNNoise lib cleaning and C-C++ porting). The first CL already went through security review, I'm addressing comments for the second. Only when the code is safe, I will add build targets.

Interesting. This should be impossible. While we do inherit the annoying behavior in sk_*_find from OpenSSL, the STACK_OF(SSL_CIPHER) should have no comparator attached to it. And indeed that NULL dereference would come from there being no comparator. But in that case, this codepath would not have been reached.

sk_SSL_CIPHER_new is never called, only sk_SSL_CIPHER_new_null. Moreover, no one calls sk_SSL_CIPHER_set_cmp_func.

I tried running the reproducer script, but it didn't trigger.

I do wonder if we can get rid of the implicit sort in sk_*_find and make it const though. It's definitely not safe to mutate that list, and it'd be nice for it to be locally obvious we're not mutating it.

The report itself appears to be some flake of some sort, possibly some unrelated component messing things up. CF hasn't been able to reproduce it more than once.

However, in investigation, Steven and I noticed some problems stemming from the current sk_*_find auto-sorting feature. We believe we can get rid of it altogether. That should, along the way, make this stack trace unreachable as opposed to merely impossible.

ClusterFuzz has detected this issue as fixed in range 549976:549977.

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

Fuzzer: attekett_dom_fuzzer
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  _quicksort
  qsort_r
  sk_find
  
Sanitizer: thread (TSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=546779:546780
Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=549976:549977

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

See https://github.com/google/clusterfuzz-tools for more information.

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

ClusterFuzz testcase 5998787743711232 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.