Marcel Laverdet

Can you run your service in a standard environment for a while and collect troubleshooting information that way? Or does this issue only show up on Lambda?

It seems like there's techniques to get a corefile or backtrace from Lambda. Have you tried, for instance, this https://stackoverflow.com/questions/53644056/aws-lambda-r-runtime-segmentation-fault

I don't recommend using node-segfault-handler. It actually causes segfaults under isolated-vm and I believe worker_threads as well. See: https://github.com/ddopson/node-segfault-handler/issues/49 You can just set `ulimit -c unlimited` and pull the stack...

Well, you have two isolates. The nodejs one and the isolated-vm one. If a segfault occurs within isolated-vm then segfault-handler will segfault itself and the debug information will be lost....

Hmm that's not a lot to go on. I'd recommend enabling `ulimit -c unlimited` and taking a peek at the corefile.

The bad news is that this error can't be fixed with a polyfill like the Array.fill issue. Even with a polyfill you could end up with `ctx.eval('eval("1".repeat(1e8) + "n")')` which...

My fix landed in v8 today -- https://chromium-review.googlesource.com/c/v8/v8/+/2384166 I can probably convince the nodejs team to cherrypick this into nodejs v14.x. I found out that this materially affects vanilla nodejs....

You can definitely report them here first. v8's parser is uninterruptible and that will probably never change. In this case, v8 gives you a hook to validate any source passed...

The `split` case is tough. v8 has a maximum array length of 0x7ffffff. If you try to allocate an array larger than this it just blows up immediately, no escape...

I resubmitted the patch after the revert and it was accepted with some broader changes: https://github.com/v8/v8/commit/7e8e76e784061277e13112c67c21c3f9438da257 https://chromium-review.googlesource.com/c/v8/v8/+/2392629