Investigate segmentation fault in cloudfare pages

Hi :smiley:

I try to deploy a gatsby website but I’m struggling with a segmentation fault:

18:44:57.878	/opt/build/bin/build: line 39:  1723 Segmentation fault      GATSBY_CPU_COUNT=2 gatsby build --verbose --log-pages
18:44:57.940	Failed: build command exited with code: 139
18:44:58.809	Failed: an internal error occurred

And it’s about all what I have :smiling_face_with_tear:

I did a lot of investigations around (versions, caching etc…) but it’s not really the point, I’m blind with this message.

Is there a way to get more details about the error by enabling any debug trace.

As far as I know, there is no option to run cloudfare pages locally (something more or less similar to act for GH actions).

I tried to emulate the cloudfare environment in a virtual machine but don’t reproduce the segfault.

Any tips to help me investigate (connect to a cloudfare page run, run close environment locally e.g docker image)?

Thank you

You can try making a NODE_OPTIONS environment variable (within the Pages project) with a value of --max-old-space-size=4096

If you wanted to try and reproduce it locally, you’d have to use gVisor with Kubernetes and use something like the Xenial build image from GitHub - netlify/build-image: This is the build image used for running automated builds

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.

2 Likes

Hello @KianNH and all :grin:

Thank you for this prompt and helpful response!

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=2G = OOM Killed
  • 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.

If you have any other advice, please share :slight_smile:

Hi,

I have a similar problem, My setup is Gatsby + Netlify CMS.

The build is failing and I can’t seem to get it to work.