Assigning to the concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/088a28287b5e289cbcf40a7977ad7a42bca42b66..1ea72f260682d39aa2a164cb650584fad2fe606d?pretty=fuller

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+log/088a28287b5e289cbcf40a7977ad7a42bca42b66..1ea72f260682d39aa2a164cb650584fad2fe606d?pretty=fuller

@rtoy -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This is a crash in PulseAudio.  Assigning to media team.

Probably some pulse bug, will take it unless you really want it tommi :)

tommi was listed as the owner of the directory, so I assigned it to him. I'm more than happy if you want to take it. :-)

I think this was just an unlucky run near OOM on the bot. I can't repro this issue; we intentionally CHECK() fail when this occurs since we don't support pulse not giving us a large enough buffer. Per crash I can't find any instances of this in the wild:

https://crash.corp.google.com/browse?q=product.name%20CONTAINS%20%27Chrome%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.file_path%20CONTAINS%20%27media%2Faudio%2Fpulse%2Fpulse_output.cc%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D

There are 18 total crashes in pulse output and they're all in other areas. So I'm inclined to mark this as WontFix unless the ClusterFuzz bot is consistently hitting this.

I have been affected by this bug, but only on one of my computers- it works fine on my other computers.

I have found there is a workaround: The bug does not appear when manually specifying an audio buffer. --audio-buffer-size=2048

For reference, here is my forum post:
https://bbs.archlinux.org/viewtopic.php?id=225820

Then there is another person who posted on a forum about it:
https://www.alionet.org/showthread.php?33100-Probl%E8me-plantage-Chromium&p=291219

Please ask away for additional information on tracking this down. For what it's worth, I would not recommend to wontfix this, because it did prevent me from using chrome at all until I discovered the workaround.

ClusterFuzz has detected this issue as fixed in range 473820:473831.

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

Fuzzer: inferno_flicker
Job Type: linux_asan_chrome_chromeos
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  bytes_to_fill == static_cast<size_t>(params_.GetBytesPerBuffer()) in pulse_outpu
  media::PulseAudioOutputStream::FulfillWriteRequest
  start_thread
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_chromeos&range=429267:429319
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_chromeos&range=473820:473831

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


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.

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

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