Cannot reproduce locally, as it only happens on windows.
Igor, you recently fixed a very similar issue in 716522, can you take a look please?

Recording a bunch of offline discussions here:

- short term, the easiest fix is to copy Igor's workaround to any additional required places.

- CodeGenerator::AssembleArchInstruction is huge: almost 1800 lines of code, 88KB release binary size (144KB in Debug mode). This is unfortunate, but there is no obvious alternative: one way or another, a large set of opcodes must be mapped onto a corresponding set of code snippets for code generation. It is debatable whether manually splitting it up into a handful of chunks would improve anything (readability or code size or whatever). The function is also quite performance sensitive.

- AssembleArchInstruction() requires only 376 bytes of stack space in release mode, but 36.8KB in Debug mode. It seems that the ASan builds that ClusterFuzz uses mirror a Debug build's behavior in this regard. Maybe there is a compiler flag we can set to enable whatever optimization pass is necessary to fold redundant stack space?

- to reproduce stack overflow issues on Linux, "ulimit -s 1024" is helpful.

ClusterFuzz has detected this issue as fixed in range 485940:486007.

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

Fuzzer: inferno_js_fuzzer
Job Type: windows_asan_d8
Platform Id: windows

Crash Type: Stack-overflow
Crash Address: 0x00752000
Crash State:
  v8::internal::compiler::CodeGenerator::AssembleInstruction
  v8::internal::compiler::CodeGenerator::AssembleCode
  v8::internal::compiler::PipelineImpl::AssembleCode
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_d8&range=450818:452941
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_d8&range=485940:486007

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


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 5674419409387520 is verified as fixed, so closing issue.

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

 Issue 763641  has been merged into this issue.

 Issue 742858  has been merged into this issue.

This is still getting reported by ClusterFuzz. We should find an ultimate solution as proposed in #2.

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

 Issue 751034  has been merged into this issue.

 Issue 752897  has been merged into this issue.

 Issue 791287  has been merged into this issue.

 Issue 796495  has been merged into this issue.

 Issue 803005  has been merged into this issue.

This crash still happens from time to time in ClusterFuzz. We should try to fix this, either by generally increasing the "red zone" on the stack (the guaranteed available space after a stack check), or by introducing more explicit stack checks in C++ code where we know that we need a lot of stack space.