eyeglass-exports: segmentation fault / abort trap

[jamesarosen]

I read through #69 and #74, which seem to be the closest to this, but I don't think are the same.

My setup

// @fastly/fui-color/package.json
"eyeglass": {
  "exports": "lib/eyeglass-exports",
  "sassDir": ".",
  "needs": "*"
},

// @fastly/fui-color/lib/eyeglass-exports.js
module.exports = function(eyeglass, sass) {
  return {
    functions: {
      'fastly-color($name)': function($name, done) {
        done(sass.types.String('#abcdef'))
      }
    },
  }
}

I'm including that in an ember app with

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

When I run ember build, it fails with

Assertion failed: (!persistent().IsWeak()), function Unref, file ../../../../nan/nan_object_wrap.h, line 107.
Abort trap: 6

If I upgrade to [email protected], it instead fails with

libc++abi.dylib: terminating with uncaught exception of type std::length_error: vector
Abort trap: 6

[jamesarosen]

Adding DEBUG=eyeglass* yields

eyeglass:modules discovered modules
  eyeglass:modules 	:root(@fastly/style-guide)
  eyeglass:modules 	├── @fastly/[email protected]
  eyeglass:modules 	└── [email protected]
  eyeglass:modules 	 +2ms
  eyeglass:functions functions discovered in module @fastly/fui-color:
	• fastly-color($name) +0ms
  eyeglass:functions functions discovered in module eyeglass:
	• eyeglass-asset-uri($registered-assets, $relative-path)
	• eyeglass-uri-preserve($uri)
	• eyeglass-uri-restore($uri)
	• eyeglass-version($module: eyeglass)
	• eyeglass-fs-absolute-path($fs-registered-pathnames, $path-id, $segments...)
	• eyeglass-fs-join($segments...)
	• eyeglass-fs-exists($absolute-path)
	• eyeglass-fs-path-separator()
	• eyeglass-fs-list-files($directory, $glob: '*')
	• eyeglass-fs-list-directories($directory, $glob: '*')
	• eyeglass-fs-parse-filename($filename)
	• eyeglass-fs-info($filename)
	• eyeglass-fs-read-file($filename) +0ms
  eyeglass:functions all discovered functions:
	• fastly-color($name)
	• eyeglass-asset-uri($registered-assets, $relative-path)
	• eyeglass-uri-preserve($uri)
	• eyeglass-uri-restore($uri)
	• eyeglass-version($module: eyeglass)
	• eyeglass-fs-absolute-path($fs-registered-pathnames, $path-id, $segments...)
	• eyeglass-fs-join($segments...)
	• eyeglass-fs-exists($absolute-path)
	• eyeglass-fs-path-separator()
	• eyeglass-fs-list-files($directory, $glob: '*')
	• eyeglass-fs-list-directories($directory, $glob: '*')
	• eyeglass-fs-parse-filename($filename)
	• eyeglass-fs-info($filename)
	• eyeglass-fs-read-file($filename) +0ms
libc++abi.dylib: terminating with uncaught exception of type std::length_error: vector
Abort trap: 6

Adding DEBUG=* adds no additional information between the eyeglass:functions all discovered functions: section and the segmentation fault.

[chriseppstein]

Hi @jamesarosen, our tests are passing with those versions of node/node-sass. Can you submit a PR for a failing test case or provide steps to reproduce without your code/app in the mix?

[jamesarosen]

I haven't totally narrowed it down yet, but [email protected] seems to have something to do with it.

$ node_modules/.bin/node-sass --version
node-sass	3.13.1	(Wrapper)	[JavaScript]
libsass  	3.3.6	(Sass Compiler)	[C/C++]

$ node_modules/node-sass/bin/node-sass --version
node-sass	3.13.1	(Wrapper)	[JavaScript]
libsass  	3.3.6	(Sass Compiler)	[C/C++]

$ node_modules/ember-freestyle/node_modules/.bin/node-sass --version
node-sass	4.7.2	(Wrapper)	[JavaScript]
libsass  	3.5.0.beta.2	(Sass Compiler)	[C/C++]

$ node_modules/ember-freestyle/node_modules/node-sass/bin/node-sass --version
node-sass	4.7.2	(Wrapper)	[JavaScript]
libsass  	3.5.0.beta.2	(Sass Compiler)	[C/C++]

[jamesarosen]

[email protected] depends on ember-cli-sass@^6.1.3, which in turn depends on broccoli-sass-source-maps@^2.0.0, which in turn depends on node-sass@^4.7.2. When I build with those dependencies, I get Segmentation fault: 11.

I've run lldb on the process to trap the segmentation fault, but the C stack trace is pretty useless inside V8.

[jamesarosen]

I don't know where node_modules/.bin/node-sass was coming from. I didn't have it listed as a direct dependency. But if I add "node-sass": "^4.0.0" as a top-level dependency, then all the versions of node-sass are 4.7.2 and all the versions of libsass are 3.5.4 and the build works fine!

So it seems the problem is related to having two conflicting sets of C symbols in the VM. I'm not sure how to force npm to blow up if it can't resolve a single version of node-sass across the board unfortunately.

[jamesarosen]

I started a conversation in the npm community to find out if it's possible to force resolution to a single version or check whether there are conflicting versions.