This isn’t going to be complete parity with the Pages build environments and is probably a lot more setup & effort than it’s worth - but the Pages team don’t really get much more information than you do about a segmentation fault.
If you can create a minimal reproducible example that’s always throwing a segmentation fault & share the repository here, they would be able to take a closer look.
I tried already NODE_OPTIONS="--max-old-space-size=4096" or even NODE_OPTIONS="--max-old-space-size=8192" it does not help.
Following your answer, I traveled the difficult path and tried to reproduce with as much parity as possible. Here are what I tried to emulate Cloud Fare pages environment:
build in docker + netlify/build:xenial = OK
build in docker + gvisor + netlify/build:xenial = OK
build in docker + gvisor + netlify/build:xenial + --memory=3G = OK
I tested with some cgroup limits (but I don’t know what are the exact values in Cloud Fare pages) to see if limited memory can induce the problem but they produce well out of memory not segmentation fault.
I tried with and without using /opt/build-bin/build to check if it could come from this functions.
Since I suppose netlify is also using the same image, I tried in netlify:
build in netlify + netlify/build:focal = OK (but timeout later at Deploy site step)
build in netlify + netlify/build:xenial = OK (but timeout later at Deploy site step)
They use by default focal but you can configure to xenial where Cloud Fare only proposes xenial so I tested both.
I don’t know what to do more without access to faulty environment, I’m probably going to build the website elsewhere and only transfer to and serve from Cloud Fare pages.
I’m a bit out of ideas for now, I will maybe try with a smaller portion of the website (and/or a reduced set of modules) to see if I can have a green build and isolate the culprit.