Looks like a plain OOM while generating RegExp code. Please confirm that this is working as intended and close if not actionable.

Weird. I remember Erik adding an upper limit to the RegExp code size. Maybe the AST is hitting OOM?

Nah, it's specifically the Assembler buffer that is OOMing, here are the top-most ten frames at the OOM site:

#0  v8::base::OS::Abort () at ../src/base/platform/platform-posix.cc:253
#1  0x0000000000faf2a8 in v8::Utils::ReportOOMFailure (location=0x221e89b "Assembler::GrowBuffer", is_heap_oom=false) at ../src/api.cc:409
#2  0x0000000000faf11d in v8::internal::V8::FatalProcessOutOfMemory (location=0x221e89b "Assembler::GrowBuffer", is_heap_oom=false) at ../src/api.cc:380
#3  0x0000000001936ceb in v8::internal::Assembler::GrowBuffer (this=0x7fffffffcb80) at ../src/x64/assembler-x64.cc:413
#4  0x0000000001033900 in v8::internal::EnsureSpace::EnsureSpace (this=0x7fffffff5668, assembler=0x7fffffffcb80) at .././src/x64/assembler-x64.h:2516
#5  0x000000000193d29a in v8::internal::Assembler::movsxlq (this=0x7fffffffcb80, dst=..., src=...) at ../src/x64/assembler-x64.cc:1646
#6  0x00000000019b7f1f in v8::internal::RegExpMacroAssemblerX64::Pop (this=0x7fffffffcb60, target=...) at ../src/regexp/x64/regexp-macro-assembler-x64.cc:1331
#7  0x00000000019becb2 in v8::internal::RegExpMacroAssemblerX64::PopCurrentPosition (this=0x7fffffffcb60) at ../src/regexp/x64/regexp-macro-assembler-x64.cc:1066
#8  0x00000000017731a8 in v8::internal::Trace::Flush (this=0x7fffffff5d38, compiler=0x7fffffffcd78, successor=0x28197d8) at ../src/regexp/jsregexp.cc:1425
#9  0x000000000177409d in v8::internal::RegExpNode::LimitVersions (this=0x28197d8, compiler=0x7fffffffcd78, trace=0x7fffffff5d38) at ../src/regexp/jsregexp.cc:2272
#10 0x000000000177e096 in v8::internal::ActionNode::Emit (this=0x28197d8, compiler=0x7fffffffcd78, trace=0x7fffffff5d38) at ../src/regexp/jsregexp.cc:4275

(gdb) f 3
(gdb) p desc.buffer_size 
$1 = 1073741824

This regexp seems to have quadratic growth in code size through backtracking (each \b causes us to backtrack through all previous \b's).

RegExpCompiler::reg_exp_too_big_ does not seem to handle this case, it is only triggered through (regexp) register allocation, TextNode::Emit and Trace::AdvanceCurrentPosition.

Yang, perhaps it'd make sense to collapse successive '\b' and '\B's? They seem to be idempotent.

collapsing makes sense. but adding more checks for size limit also makes sense, to catch similar issues.

 Issue 702135  has been merged into this issue.

We don't have a mechanism to abort regexp code generation and I don't see an easy way to add code size checks.

Opened  crbug.com/v8/6126  for collapsing repeated boundary check nodes and closing the OOM as not actionable.

Acknowledged. Will triage further OOM reports by ClusterFuzz accordingly. Thanks!

ClusterFuzz has detected this issue as fixed in range 458726:458740.

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

Fuzzer: libfuzzer_v8_regexp_parser_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Fatal error
Crash Address: 
Crash State:
  v8::Isolate::Dispose
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=415619:415673
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=458726:458740

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv95a9LOmJspTVYB1Dg_29-mw2wQtl-_y5sK7ix5NMbHgoIppUE0tElGr2eCIye3pKFt9qoxTs7RRQv7DGd44t3pReXmKLQt6lTeHBwkDDDDdjvc7WM9BQymE1GAoXJjhYKnVKXzv3BLdVhm1o4Thlba2Y0WQqxqwrFgZ71-UqCEQHprBLv9-r7Opy5wftkontOk9g879z8l9a22BEQl0T7xorKHVYpEPmLSINj63aO9l_QJDcfv5Q4gFRs64nasm22gWEDB0exIH27coHuOpi_-cN7MlSrvdF2y7dRiU7XQR14jvP80TPyxbjj9BWzvWZSIRL988EiDDMeoGezGXTMwmXnHg9xROkGF3l4dkD6t7Py7i5ao?testcase_id=5562481339793408


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

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

 Issue 735559  has been merged into this issue.

 Issue 759531  has been merged into this issue.

 Issue 760599  has been merged into this issue.

 Issue 761133  has been merged into this issue.

 Issue 765981  has been merged into this issue.

 Issue 778948  has been merged into this issue.

 Issue 784034  has been merged into this issue.