Getting ECONNRESET error

[vast]

OS: Ubuntu 14.04.
Both Imagemagick and GraphicMagick are installed.
gm version: 1.19.0
GraphicMagick version: 1.3.18.

Stacktrace:

Error: Error: read ECONNRESET
    at finish (/home/runner/test/node_modules/paper/node_modules/gulp-image-resize/node_modules/gulp-gm/index.js:41:21)
    at gm.<anonymous> (/home/runner/test/node_modules/paper/node_modules/gulp-image-resize/node_modules/async/lib/async.js:485:30)
    at gm.emit (events.js:118:17)
    at gm.<anonymous> (/home/runner/test/node_modules/paper/node_modules/gulp-image-resize/node_modules/gulp-gm/node_modules/gm/lib/getters.js:70:16)
    at Socket.cb (/home/runner/test/node_modules/paper/node_modules/gulp-image-resize/node_modules/gulp-gm/node_modules/gm/lib/command.js:322:16)
    at Socket.g (events.js:199:16)
    at Socket.emit (events.js:107:17)
    at net.js:459:14
    at process._tickCallback (node.js:355:11)

Any help or ideas?

[vast]

Update: downgrading to the previous version (1.18.1) fixes the issue.

[rwky]

Do you have sample code/images?

[hughstephens]

Getting the same issue. Almost anything uploaded will fail when trying to .size() on 1.19.0 – 1.18.1 is fine. Will try and put some more info together, but it's pretty consistent...

[sballesteros]

same here, will try to isolate and report.

[rwky]

#446 is probably related.

A quick fyi. I've no idea if gm works in node 4.0 (or 4.1) I've not tried it and due to the fast development pace of the 4.x branch I'll wait a bit before trying it.

If someone can put up reproducible code and images by Monday I can take a look next week, all tests are passing so it must be something we don't test for 😞

[vast]

@rwky, isolated it to large jpg/png. Please have a look at: https://github.com/vast/gm-448

⌘ ~/src/gm-448/ (master): ./node_modules/.bin/gulp 
[20:02:39] Using gulpfile ~/src/gm-448/gulpfile.js
[20:02:39] Starting 'default'...

events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: Error: write EPIPE
    at finish (/Users/vast/src/gm-448/node_modules/gulp-image-resize/node_modules/gulp-gm/index.js:40:21)
    at gm.<anonymous> (/Users/vast/src/gm-448/node_modules/gulp-image-resize/node_modules/async/lib/async.js:485:30)
    at gm.emit (events.js:118:17)
    at gm.<anonymous> (/Users/vast/src/gm-448/node_modules/gulp-image-resize/node_modules/gulp-gm/node_modules/gm/lib/getters.js:70:16)
    at Socket.cb (/Users/vast/src/gm-448/node_modules/gulp-image-resize/node_modules/gulp-gm/node_modules/gm/lib/command.js:318:16)
    at Socket.g (events.js:199:16)
    at Socket.emit (events.js:107:17)
    at onwriteError (_stream_writable.js:317:10)
    at onwrite (_stream_writable.js:335:5)
    at WritableState.onwrite (_stream_writable.js:105:5)

[rwky]

Excellent, I can reproduce it using that repo, leave it with me.

[rwky]

This is really weird. I've pinned it down to this line

gm/index.js

Line 77 in 38f5f55

if (inputFromStdin && this.source && this.source !== 'unknown.jpg') ret = this.source.split('.').pop() + ':-';

For some reason adding png: before - causes gm to close the pipe early (I'm assuming it's gm and not node being weird).

Unless anyone else can come up with a better solution I'll have to revert that commit which is a shame since it's useful.

[kapouer]

Same here on debian/sid when generating large (750x19000) jpg with
graphicsmagic 1.3.21
gm 1.19.0
nodejs 4.1.0

[omahm]

Not just large images, I'm getting this with small jpgs (580 x 320 ~ <100kb) as part of a Gulp task using gulp-image-resize

OSX 10.10.5
graphicsmagic 1.3.21
gm 1.19.0

[rwky]

Can someone please test the issue-448 branch and confirm that this is resolved? If so I'll merge it in and release a new version to npm.

[kapouer]

@rwky i can confirm that it works

[rwky]

OK 1.20.0 is in npm I'll close this.

[adurrive]

@rwky it's gm that closes the pipe early. I've faced this issue randomly, depending on the system I tested it on, but in each case I could reproduce it with:

cat Periodic_table_large.png | gm identify -

/tmp/gmOqtzBC PNG 6000x3300+0+0 DirectClass 8-bit 2.2M 0.000u 0:01

cat Periodic_table_large.png | gm identify png:-

- PNG 6000x3300+0+0 DirectClass 8-bit 0.000u 0:01
cat: write error: Broken pipe

The result is always unaltered. I assume it is the expected behaviour from gm since it doesn't create a temp file in the second case and may therefore not need to wait for the whole file. The missing total file size (2.2M) comfort this idea. It seems also slightly faster (testing with wget). Ignoring the broken pipe should be safe in this case.