Gatsby: [bug]: sharp and image processing failures

[DSchau]

Description

In this issue, I'd like to collect _any_ issues others have run into regarding image processing failures with Gatsby. These should be focused on build failures and not warnings. For instance--if a failure occurred installing Sharp, note what the error message was and _any_ additional environment details that would be helpful for debugging the issue. Typically, these will be things like Node version, version of gatsby, version of sharp, etc. (gatsby info --clipboard will be _very_ helpful here) and consider following the template below to craft your reply.

Also note: this is not only for issues that you don't have a solution for. If you had an issue with image processing + Gatsby and were able to solve it, please 1) edit/update your reply, or 2) provide a comment with the fix.

But... why?

If we can track on the most common issues people are encountering, we can make upstream improvements to our dependencies and also update our documentation to avoid issues in the future, where appropriate. Win/win!

Template

Please use the below template to add your issue, if at all possible!

## High-level error message or summary

> Paste the actual one or two line error

### Solution

<!-- If applicable -->

### Stacktrace

<!-- Full stacktrace, if applicable -->

### Environment info

<!-- Please paste the result of `npx gatsby clipboard --info` or `gatsby clipboard --info` if globally installed -->

[DSchau]

xcode-tools error with Node 9

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

Solution

1. rm -rf node_modules
2. sudo xcode-select --switch /Library/Developer/CommandLineTools reference
3. Close current terminal instance, and open new one
4. Re-run npm install

Stacktrace

info sharp Using cached /Users/dschau/.npm/_libvips/libvips-8.7.0-darwin-x64.tar.gz
prebuild-install WARN install No prebuilt binaries found (target=9.11.2 runtime=node arch=x64 platform=darwin)
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

Traceback (most recent call last):
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py", line 16, in <module>
    sys.exit(gyp.script_main())
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 545, in script_main
    return main(sys.argv[1:])
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 538, in main
    return gyp_main(args)
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 523, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/generator/make.py", line 2170, in GenerateOutput
    part_of_all=qualified_target in needed_targets)
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/generator/make.py", line 795, in Write
    self.Pchify))
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/generator/make.py", line 1190, in WriteSources
    cflags = self.xcode_settings.GetCflags(configname)
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/xcode_emulation.py", line 551, in GetCflags
    archs = self.GetActiveArchs(self.configname)
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/xcode_emulation.py", line 420, in GetActiveArchs
    xcode_archs_default = GetXcodeArchsDefault()
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/xcode_emulation.py", line 118, in GetXcodeArchsDefault
    xcode_version, _ = XcodeVersion()
  File "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/xcode_emulation.py", line 1265, in XcodeVersion
    version = re.match(r'(\d\.\d\.?\d*)', version).groups()[0]
AttributeError: 'NoneType' object has no attribute 'groups'
gyp ERR! configure error 
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:336:16)
gyp ERR! stack     at ChildProcess.emit (events.js:180:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:12)
gyp ERR! System Darwin 18.2.0
gyp ERR! command "/Users/dschau/.nvm/versions/node/v9.11.2/bin/node" "/Users/dschau/.nvm/versions/node/v9.11.2/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/dschau/Code/Work/gatsby/test/10816/node_modules/sharp
gyp ERR! node -v v9.11.2
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok 
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: `(node install/libvips && node install/dll-copy && prebuild-install) || (node-gyp rebuild && node install/dll-copy)`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Environment Info

  System:
    OS: macOS 10.14.2
    CPU: x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 9.11.2 - /usr/local/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 64.0
    Safari: 12.0.2
  npmGlobalPackages:
    gatsby-cli: 2.4.2
    gatsby-dev-cli: 2.4.7
    gatsby: 2.0.14

[joelhooks]

I've got a set of images linked from mdx files that are consistently skipped during gatsby build process. This can be observed in this branch.

The result occurs both locally and when deployed. Click here for the netlify preview built

Also worth noting that the images are repeated in two images subfolders under /content/blog and fail to process in both.

The images appear as expected in development with gatsby develop

No errors, traces, warnings, or other indications of failure occur.

[arturhenryy]

i would like to reference this issue here #10347
localfile creation for images are silently failing.
it is already recognized as a bug but it seems that it has been forgotten about, although this is a pretty critical bug imo.

[sidharthachatterjee]

Related issues at https://github.com/gatsbyjs/gatsby/issues/8301 and https://github.com/gatsbyjs/gatsby/issues/10620

[DSchau]

Incompatible library version: libvips-cpp.dylib

error Plugin gatsby-transformer-sharp returned an error
Error: dlopen(/Users/dschau/Code/Work/gatsby/test/test-gatsby/node_modules/gatsby-plugin-sharp/node_modules/sharp/build/Release/sharp.node, 1): Libr ary not loaded: @rpath/libvips.42.dylib
Referenced from: /Users/dschau/Code/Work/gatsby/test/test-gatsby/node_modules/gatsby-plugin-sharp/node_modules/sharp/vendor/lib/libvips-cpp.42.dyl ib
Reason: Incompatible library version: libvips-cpp.dylib requires version 52.0.0 or later, but libvips.42.dylib provides version 51.0.0

Solution

In general--it seems like this issue is because two versions of sharp are being used by separate plugins. We can resolve this with resolutions field, but the better solution is to align deps (and upgrade) to the latest gatsby-* plugins.

1. rm -rf node_modules
2. yarn why sharp
shell => Found "[email protected]" info Has been hoisted to "sharp" info Reasons this module exists <ul> <li>Hoisted from "gatsby-plugin-sharp#sharp"</li> <li>Hoisted from "gatsby-transformer-sharp#sharp"<br /> info Disk size without dependencies: "27.98MB"<br /> info Disk size with unique dependencies: "29.05MB"<br /> info Disk size with transitive dependencies: "31.38MB"<br /> info Number of shared dependencies: 55<br /> =&gt; Found "gatsby-plugin-manifest#<a href="[email protected]">[email protected]</a>"<br /> info This module exists because "gatsby-plugin-manifest" depends on it.<br /> info Disk size without dependencies: "29.01MB"<br /> info Disk size with unique dependencies: "30.07MB"<br /> info Disk size with transitive dependencies: "32.39MB"<br /> info Number of shared dependencies: 54<br /> ✨ Done in 0.84s.<br />


3. Add a resolutions field to package.json with the latest version of sharp
   json "resolutions": { "sharp": "0.21.1" }
4. Re-run yarn to install the dependencies with the shared version of sharp

This is a pretty challenging one to solve--and there doesn't appear to be a trivial solution that we can implement outside of yarn resolutions

See this repo for a reproduction.

Stacktrace

error Plugin gatsby-transformer-sharp returned an error


  TypeError: getNodesByType is not a function

  - gatsby-node.js:22 Object.<anonymous>
    [test-gatsby]/[gatsby-transformer-sharp]/gatsby-node.js:22:9

  - Generator.next

  - debuggability.js:313 Promise._execute
    [test-gatsby]/[bluebird]/js/release/debuggability.js:313:9

  - promise.js:483 Promise._resolveFromExecutor
    [test-gatsby]/[bluebird]/js/release/promise.js:483:18

  - promise.js:79 new Promise
    [test-gatsby]/[bluebird]/js/release/promise.js:79:10

  - gatsby-node.js:31 Object.onPreExtractQueries
    [test-gatsby]/[gatsby-transformer-sharp]/gatsby-node.js:31:17

  - api-runner-node.js:150 runAPI
    [test-gatsby]/[gatsby]/dist/utils/api-runner-node.js:150:37

  - api-runner-node.js:260 Promise.mapSeries.plugin
    [test-gatsby]/[gatsby]/dist/utils/api-runner-node.js:260:32

  - util.js:16 tryCatcher
    [test-gatsby]/[bluebird]/js/release/util.js:16:23

  - reduce.js:155 Object.gotValue
    [test-gatsby]/[bluebird]/js/release/reduce.js:155:18

  - reduce.js:144 Object.gotAccum
    [test-gatsby]/[bluebird]/js/release/reduce.js:144:25

  - util.js:16 Object.tryCatcher
    [test-gatsby]/[bluebird]/js/release/util.js:16:23

Environment info

  System:
    OS: macOS 10.14.2
    CPU: x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.6.0 - /usr/local/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.5.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 64.0
    Safari: 12.0.2
  npmPackages:
    gatsby: ^2.0.19 => 2.0.28 
    gatsby-image: ^2.0.16 => 2.0.25 
    gatsby-plugin-layout: ^1.0.3 => 1.0.11 
    gatsby-plugin-manifest: ^2.0.5 => 2.0.5 
    gatsby-plugin-offline: ^2.0.5 => 2.0.7 
    gatsby-plugin-react-helmet: ^3.0.0 => 3.0.0 
    gatsby-plugin-sharp: ^2.0.7 => 2.0.17 
    gatsby-source-prismic: ^2.0.0 => 2.2.0 
    gatsby-transformer-sharp: ^2.1.4 => 2.1.10 
  npmGlobalPackages:
    gatsby-cli: 2.4.2
    gatsby-dev-cli: 2.4.7
    gatsby: 2.0.14

[polarathene]

Error: VipsImage: unable to write to

Attempting to build the example using-gatsby-image fails, no changes made.

libvips should be installed fine afaik as it's worked on other projects with the Docker image I've been using. I am copying over my own binaries/versions for libvips(8.7.0), and imagemin mozjpeg,cwebp-bin,pngquant-bin for musl compatible versions.

Stacktrace

error Failed to process image /site/.cache/gatsby-source-filesystem/d1ab1dbb3ab71d828ca1bb0c2f95bcfc/photo-1505904909252-8ce17de9f287.jpg


  Error: VipsImage: unable to write to "/tmp/vips-0-394339043.v"
  unix error: Not supported

(sharp:41): GLib-CRITICAL **: 02:50:27.966: g_hash_table_lookup: assertion 'hash_table != NULL' failed

(sharp:41): GLib-CRITICAL **: 02:50:28.050: g_hash_table_lookup: assertion 'hash_table != NULL' failed

I can confirm that libvips has written jpg images to /tmp successfully, just not this .v file.

The later lines about GLib I'm not sure if they're actually related from what I've read about the error, though this is Alpine which uses musl instead of libc, but I am using the correct version, pulling the following:

LIBVIPS_VERSION="8.7.0"
LIBVIPS_PLATFORM="linuxmusl"
"https://github.com/lovell/sharp-libvips/releases/download/v${LIBVIPS_VERSION}/libvips-${LIBVIPS_VERSION}-${LIBVIPS_PLATFORM}-x64.tar.gz" 

Solution

Turns out to be a problem with running libvips on Alpine and writing to /tmp. There is an expected fix with upcoming 8.7.1.

Environment info

gatsby info seems to just hang, I assume it's trying to do something that isn't supported on Alpine or that I'm missing a package for. gatsby -v outputs v2.4.8.

package.json:

{
  "name": "using-gatsby-image",
  "private": true,
  "description": "Gatsby example site using using-gatsby-image",
  "author": "Kyle Mathews <[email protected]>",
  "dependencies": {
    "emotion": "^9.2.12",
    "emotion-server": "^9.2.12",
    "gatsby": "^2.0.36",
    "gatsby-image": "^2.0.19",
    "gatsby-plugin-emotion": "^2.0.6",
    "gatsby-plugin-netlify": "^2.0.3",
    "gatsby-plugin-sharp": "^2.0.11",
    "gatsby-plugin-typography": "^2.2.1",
    "gatsby-source-filesystem": "^2.0.7",
    "gatsby-transformer-sharp": "^2.1.7",
    "gatsby-transformer-yaml": "^2.1.4",
    "numeral": "^2.0.6",
    "react": "^16.6.0",
    "react-dom": "^16.6.0",
    "react-emotion": "^9.2.12",
    "react-icons": "^3.2.1",
    "react-typography": "^0.16.13",
    "typeface-oswald": "0.0.54",
    "typeface-pt-sans": "0.0.54",
    "typography": "^0.16.6"
  },
  "license": "MIT",
  "main": "n/a",
  "scripts": {
    "develop": "gatsby develop",
    "build": "gatsby build",
    "start": "npm run develop"
  }
}

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[endymion1818]

I'm a little late to the party but several members of my team are experiencing issues with libpng, and pngquant, where, when you install these globally using brew on macOS Mojave, one does not seem to recognise the other is present, and builds fail:

success extract queries from components — 0.296 s
error UNHANDLED REJECTION


 Error: Failed to process image
<imagepath>

Out of 12 people who should be able to run this project, only 2 are currently able to due to this issue ...

We've tried installing & uninstalling the libraries, re-installing node_modules and can't seem to find what's causing the issue.

UPDATE: we've tried everything, from removing brew and reinstalling, and node. However nothing seems to be working at all. Think we're going to be have to stop using gatsby-image soon :-(

[alexanderwe]

Fail to process .jpg images

I am trying to use gatsy-plugin-sharp with gatsby-source-wordpress. The Wordpress instance contains around 600 images, including some large images with around 5-6mb. The processing of the images fails randomly, every time with another image, but it seems it's always a .jpg but not with a max. file size. Sometimes an image with 5mb fails, sometimes it's a 2mb one.

It's a project for a photography portfolio so it's quite crucial that the image processing succeeds but I have no clue of how this could be solved.

I tried deleting .cache, npm_modules and the public directory but without success.

I am using the following dependencies:

"babel-plugin-styled-components": "1.10.0",
"gatsby-image": "2.0.40",
"gatsby-plugin-manifest": "2.0.29",
"gatsby-plugin-page-creator": "2.0.12",
"gatsby-plugin-react-helmet": "3.0.12",
"gatsby-plugin-sharp": "2.0.35",
"gatsby-plugin-sitemap": "2.0.12",
"gatsby-plugin-styled-components": "3.0.7",
"gatsby-plugin-typography": "2.2.13",
"gatsby-source-instagram": "0.5.0",
"gatsby-source-wordpress": "3.0.57",
"gatsby-transformer-sharp": "2.1.18",
"gatsby-wordpress-inline-images": "1.0.0",
"react-helmet": "5.2.0",
"react-images": "0.5.19",
"react-media": "1.9.2",
"react-photo-gallery": "7.0.2",
"react-typography": "0.16.19",
"styled-components": "4.2.0",
"typography": "0.16.19"

Stacktrace

error UNHANDLED REJECTION

Error: Failed to process image /Users/user/Documents/Programming/gatsby-projects/theme/si  te/.cache/gatsby-source-filesystem/62461a03baef7bca3600a0cbdcf7de5d/L1009643.jpg

(sharp:67220): GLib-CRITICAL **: 14:34:59.191: g_hash_table_lookup: assertion 'hash_table != NULL' failed

(sharp:67220): GLib-CRITICAL **: 14:34:59.192: g_hash_table_lookup: assertion 'hash_table != NULL' failed

(sharp:67220): GLib-CRITICAL **: 14:34:59.192: g_hash_table_insert_internal: assertion 'hash_table != NULL' failed

(sharp:67220): GLib-CRITICAL **: 14:34:59.192: g_hash_table_lookup: assertion 'hash_table != NULL' failed
error Command failed with signal "SIGSEGV".

Environment info

  System:
    OS: macOS 10.14.4
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.15.3 - /var/folders/8g/thhx4y056s92_s9xqfytf6ww0000gn/T/yarn--1556539822116-0.773076380910849/node
    Yarn: 1.15.2 - /var/folders/8g/thhx4y056s92_s9xqfytf6ww0000gn/T/yarn--1556539822116-0.773076380910849/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.15.3/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Firefox: 66.0.3
    Safari: 12.1

[arturhenryy]

@alexanderwe
https://github.com/gatsbyjs/gatsby/issues/10347. there is a pull request waiting for this issue. you could test it if you have some time. will do the testing tomorrow as well.

[alexanderwe]

@arturhenryy Thanks for pointing me to the pull request. I will try to test it. But if I get it correct this pull request is about images not being downloaded correctly ? Do you think this is the root cause of getting this != null failures ? Because when I view the images in the file directory the user half of the image is correctly displayed but the lower half is just grey with missing pixel information.

[jonniebigodes]

@alexanderwe i've been trying to tackle a issue that is somewhat similar to yours. And from my experimentation with a 200+ data set with a average(not really a exact one) of 3MB and factoring the Gatsby website pipeline process, it would be stuck. Or the images were not correctly downloaded. I was facing a file corruption of upwards of 80%, my reasoning is that as there's alot of moving parts going on at the same time and probably some stuff is working synchronously and some asynchronously. Namely the images are pulled in by a package that handles the download, pipelined into node, that in turn pipelines it into the packages that handle the file creation on the disk(synch or async) and generate the responsive image files and add the graphql nodes. Been a long time since i touched the c or c++ language my my take on this is that the libvips library is eagerly trying to manipulate the image when the image is not actually fully downloaded yet. The space is allocated in the filesystem and some data is present but not all, it detects it and starts to work on it. Now while it's doing it's work as there's insuficient data in there some calculations done might lead to parts that don't exist, and it starts throwing those kind of errors. And it bubbles back to node and Gatsby. There could be a race condition somewhere that was overlooked or is being generated by some of the parties involved.

[alexanderwe]

@jonniebigodes Sounds like a reasonable cause of this problem. Especially since I see the corrupted images on my file system. Do you have a starting point where one could start to solve this issue ?

Maybe the pull request @arturhenryy mentioned might be good enough for a quick fix, but I am not sure.

[jonniebigodes]

For me, for the issue i'm trying to solve, what somewhat worked, i haven't fully "battle tested" (pardon the bad pun) it yet, but for now locally i was able to fetch the 200+ images and save them with 0% data corruption was through the use of the api function onPreBootstrap. I use it to fetch the data i want, make some transformations and replicate a folder structure needed. Then start the download of the images, doing this recursively, Only when the current image has finished downloading then i move onto the next one and so on. Now in terms of time, it takes a bit of time to fetch, also when running it the console will be throwing logs "left and right"(once again pardon the bad pun), meaning that Gatsby has picked up that the image is now present and inform me.
Now for the case at hand, using the plugins, from my understanding of the Gatsby build pipeline and i might be completely wrong about this but, when it reaches the plugins stage, the onPreBootstrap is probably not accessible and with that one cannot go back in time. So applying my approach would be rather impossible with that api call, also the same could be said with the onPreBuild . Now i've been reading the gatsby-source-wordpress and how it handles the file download and that led me to gatsby-source-filesystem plugin, more exactly to create-remote-file-node.js and this has been bugging me. If my read on the finish event is correct, technically Gatsby/node is bailing out on the end of the stream. Is my read on this correct? Also once again, if my read on the events is correct, shouldn't it be "listening" for close? So that it unsures that all the information is the user's side? Just my 2 cents on this. I might be completely off base here, and i'll leave it to more knowledgeable people.

[michaeldrawe]

I had this error all of a sudden. I tried as DSchau had suggested, I removed node_modules, re-ran npm install, and the site could be built without problem.

Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04

[jonniebigodes]

Adding a little more context on my previous comment, looks like my testing methodology was a little biased, i was only focusing on the image download, adding image injection via graphql breaks the build all together, either in development mode or production mode. Using the onPreBoostrapwith a recursive function to download the files without any reference to graphql will get me a 0% image loss. Now when i added graphql and gatsby-image to the mix, it's when all goes up. Applying a synchronous approach to the onPreBoostrap, getting the data needed, i was under the assumption that the build would wait for the code to run to completion and then move along. The process continues and it starts to throw errors. Tried a couple of permutations as for instance remove all of the graphql from the pages/components either with StaticQuery and page queries and move it into createPages API yelded the exact same result.

[Saint2Laurent]

Hey there, I am trying to build my project and I am stumbling across the same Issue here.
When trying to build it locally it completes normally but when I am trying to build it on my VPS, I am getting the following error:
I think it got something to do either with the operating system or with the RAM available, Im not sure tho.

ERROR

UNHANDLED REJECTION {
err: Error: spawn ENOMEM
at ChildProcess.spawn (internal/child_process.js:394:11)
at Object.spawn (child_process.js:542:9)
at module.exports (/root/roundtravel/client/node_modules/execa/index.js:139:26)
at /root/roundtravel/client/node_modules/exec-buffer/index.js:35:15 {
errno: 'ENOMEM',
code: 'ENOMEM',
syscall: 'spawn'
},
message: 'Failed to process image /root/roundtravel/client/src/images/paris-garden.jpg'
}

Error: {
err: Error: spawn ENOMEM

• child_process.js:394 ChildProcess.spawn
  internal/child_process.js:394:11

• index.js:139 module.exports
  [client]/[execa]/index.js:139:26

• errno: 'ENOMEM',

• code: 'ENOMEM',

• syscall: 'spawn'

• },

• message: 'Failed to process image /root/roundtravel/client/src/images/paris-garden.jpg'

• }

• index.js:101 process.
  [client]/[gatsby]/[gatsby-cli]/lib/index.js:101:14

• index.js:155 processEmit [as emit]
  [client]/[signal-exit]/index.js:155:32

• promises.js:201 processPromiseRejections
  internal/process/promises.js:201:33

• task_queues.js:86 processTicksAndRejections
  internal/process/task_queues.js:86:32

⠇ Building production JavaScript and CSS bundles
[==================== ] 144.986 s 13/18 72% Generating image thumbnails

(sharp:24620): GLib-CRITICAL **: 11:11:19.033: g_hash_table_lookup: assertion 'hash_table != NULL' failed

(sharp:24620): GLib-CRITICAL **: 11:11:22.773: g_hash_table_lookup: assertion 'hash_table != NULL' failed

(sharp:24620): GLib-CRITICAL **: 11:11:24.800: g_hash_table_lookup: assertion 'hash_table != NULL' failed

Currently there are 31 Images inside my images folder and 13 of them are svg Icons, rest are JPG images. Please keep in mind that I've created an Image components which recieves the filename and after querying with staticQuery I am filtering the result via js for each image.

System:
OS: Linux 4.15 Ubuntu 18.04.2 LTS (Bionic Beaver)
CPU: (1) x64 Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 12.6.0 - /usr/local/bin/node
npm: 6.9.0 - /usr/local/bin/npm
Languages:
Python: 2.7.15+ - /usr/bin/python
npmPackages:
gatsby: ^2.13.50 => 2.13.50
gatsby-background-image: ^0.8.2 => 0.8.2
gatsby-image: ^2.2.6 => 2.2.6
gatsby-plugin-manifest: ^2.2.4 => 2.2.4
gatsby-plugin-offline: ^2.2.4 => 2.2.4
gatsby-plugin-react-helmet: ^3.1.2 => 3.1.2
gatsby-plugin-sass: ^2.1.3 => 2.1.3
gatsby-plugin-sharp: ^2.2.10 => 2.2.10
gatsby-source-filesystem: ^2.1.5 => 2.1.5
gatsby-transformer-sharp: ^2.2.4 => 2.2.4
npmGlobalPackages:
gatsby-cli: 2.7.19

These are my clipboard information above.
I've also tried to run my build this way "node --max_old_space_size=4096 ./node_modules/.bin/gatsby build" and increasing the ram size available to the build but no luck in this manner also.

Steps to reproduce:
Clone the following repository:
https://github.com/Saint2Laurent/roundtravel
Gatsby client is located inside /client

Is there anything else I should try?
Thanks a lot to all those guys contributing, wish I was able to do so too but sadly I'm not as familiar as needed like with those technologies.

[alexanderwe]

@Saint2Laurent I see your images are quite large. It could resolve some of my issues by shrinking my image sizes. So my images are around 500kb-1mb and are processed fine on Netlify

[arturhenryy]

@Saint2Laurent
this error occurs when your server has no or not enough swapspace available. check this thread. not really related to the original question here
https://stackoverflow.com/questions/26193654/node-js-catch-enomem-error-thrown-after-spawn

[Saint2Laurent]

@arturhenryy
Hey artur, thanks for your response, this was indeed related to having no swapspace available, I followed the instructions in the stackoverflow link you provided and it build successfully,
Thanks a lot!

[ehannes]

Unable to build Sharp

Can't run a fresh yarn install.

../src/common.cc:25:10: fatal error: vips/vips8: No such file or directory
 #include <vips/vips8>

Reproducing

Run gatsby new, remove all but the below in package.json, delete node_modules and run yarn install.

{
  "dependencies": {
    "gatsby": "^2.13.73",
    "gatsby-plugin-manifest": "^2.2.6",
    "styled-components": "^4.3.2"
  }
}

If I remove styled-components it works great, but I think there are more plugins that can be the third plugin in the dependencies list above and still reproduce the same error.

Solution

Currently, I need to remove the gatsby-plugin-manifest, run yarn install and then add it with yarn add gatsby-plugin-manifest.

Stacktrace

[4/4] Rebuilding all packages...
[-/5] ⠠ waiting...
[-/5] ⠠ waiting...
[-/5] ⠠ waiting...
[4/5] ⠠ sharp
error /home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/sharp: Command failed.
Exit code: 1
Command: (node install/libvips && node install/dll-copy && prebuild-install) || (node-gyp rebuild && node install/dll-copy)
Arguments:
Directory: /home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/sharp
Output:
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp info spawn /usr/bin/python2
gyp info spawn args [ '/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/sharp/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/home/hannes/.node-gyp/10.16.1/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/home/hannes/.node-gyp/10.16.1',
gyp info spawn args   '-Dnode_gyp_dir=/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/home/hannes/.node-gyp/10.16.1/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/sharp',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.' ]
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory '/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/sharp/build'
  TOUCH Release/obj.target/libvips-cpp.stamp
  CXX(target) Release/obj.target/sharp/src/common.o
  ../src/common.cc:25:10: fatal error: vips/vips8: No such file or directory
   #include <vips/vips8>
            ^~~~~~~~~~~~
compilation terminated.
sharp.target.mk:128: recipe for target 'Release/obj.target/sharp/src/common.o' failed
make: Leaving directory '/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/sharp/build'
make: *** [Release/obj.target/sharp/src/common.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Linux 5.0.0-23-generic
gyp ERR! command "/snap/node/2485/bin/node" "/home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/.bin/node-gyp" "rebuild"
gyp ERR! cwd /home/hannes/workspace/mycompany/myproject/gatsby-theme/node_modules/sharp

Environment info

$ gatsby info
  System:
    OS: Linux 5.0 Pop!_OS 18.04 LTS
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Shell: 4.4.20 - /bin/bash
  Languages:
    Python: 2.7.15+ - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.100
    Firefox: 68.0.1

$ node --version
v10.16.1

I have installed node as a snap package:

$ snap list node
Name  Version  Rev   Tracking  Publisher    Notes
node  10.16.1  2485  10        nodesource✓  classic

[aconnor731]

Unable to build sharp

Error: {
    err: Error: /home/austin/repos/gatsby/gatsby-intro/node_modules/cwebp-bin/vendor/cwebp: error while loading shared   libraries: libXi.so.6: cannot open shared object file: No such file or directory

Solution

Remove gatsby-plugin-manifest, run yarn install, re-install gatsby-plugin-manifest

Stacktrace

I'm not sure how to do this.

Environment info

System:
    OS: Linux 4.15 Ubuntu 18.04.3 LTS (Bionic Beaver)
    CPU: (1) x64 Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
    Shell: 4.4.20 - /bin/bash
  Binaries:
    Node: 12.12.0 - ~/.nvm/versions/node/v12.12.0/bin/node
    npm: 6.11.3 - ~/.nvm/versions/node/v12.12.0/bin/npm
  npmPackages:
    gatsby: ^2.16.4 => 2.16.4
    gatsby-background-image: ^0.8.15 => 0.8.15
    gatsby-cli: ^2.7.58 => 2.7.58
    gatsby-image: ^2.2.25 => 2.2.25
    gatsby-plugin-emotion: ^4.1.10 => 4.1.10
    gatsby-plugin-manifest: ^2.2.21 => 2.2.21
    gatsby-plugin-mdx: ^1.0.50 => 1.0.50
    gatsby-plugin-offline: ^3.0.13 => 3.0.13
    gatsby-plugin-react-helmet: ^3.1.11 => 3.1.11
    gatsby-plugin-sharp: ^2.2.29 => 2.2.29
    gatsby-plugin-webpack-bundle-analyzer: ^1.0.5 => 1.0.5
    gatsby-remark-images: ^3.1.26 => 3.1.26
    gatsby-source-filesystem: ^2.1.31 => 2.1.31
    gatsby-source-instagram: ^0.5.1 => 0.5.1
    gatsby-transformer-sharp: ^2.2.21 => 2.2.21
  npmGlobalPackages:
    gatsby-cli: 2.8.2

[sidharthachatterjee]

Thank you all of you for your reports here. Stability with respect to sharp has been improved since and we've added useful warnings for some of these common cases.

Let's close this umbrella issue for now and open independent issues for any more instances of errors we see with sharp

Thank you once again! 💜