Segfault with Angular2/Webpack/Material2 Theming (linux only)

[netmikey]

• NPM version (npm -v): 3.10.3
• Node version (node -v): v6.7.0
• Node Process (node -p process.versions):

{ http_parser: '2.7.0',
  node: '6.7.0',
  v8: '5.1.281.83',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '56.1',
  modules: '48',
  openssl: '1.0.2j' }

• Node Platform (node -p process.platform): linux
• Node architecture (node -p process.arch): x64
• node-sass version (node -p "require('node-sass').info"):

node-sass   3.10.1  (Wrapper)   [JavaScript]
libsass     3.3.6   (Sass Compiler) [C/C++]

• npm node-sass versions (npm ls node-sass):

myproject@0.0.0 /root/crap/myproject
└─┬ angular-cli@1.0.0-beta.16
  └── node-sass@3.10.1 

---

Before I start, let me apologise: I am setting up a new Angular2 project with the angular-cli and angular-material2, but I'm a SASS novice so I have been unable to extract the exact sass lines causing the issue.

What I do have though, is a reduced test project based on an empty angular-cli project template and just enough modification to cause the segmentation fault I'm seeing. Since I pretty much only followed the docs, I'm afraid there might be quite some people running into this right now. I hope this helps reproducing and eventually fixing it. Let me know if there's more I can do.

So what I did was adding a custom angular-material2 theme. As soon as I add the sass file from the documentation, the webpack build fails with a segmentation fault. The error only occurs on linux (debian wheezy in my case), on macOS using the same Node/npm versions, it works fine. Also, I've been able to track down the node-sass version where this startet happening: it used to work up to v3.5.3 and started failing as of v3.6.0.

Finally, I've tried to let gdb give me a stacktrace, but since I don't have a Node binary with debug symbols, I'm not sure whether it is of much use to you guys. Anyway, here is the full output:

Could not start watchman; falling back to NodeWatcher for file system events.
Visit http://ember-cli.com/user-guide/#watchman for more info.
** NG Live Development Server is running on http://localhost:4200. **
 69% building modules 812/813 modules 1 active ...root/crap/myproject/src/md-theme.scss  
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffef7fe700 (LWP 14644)]
0x00007fffee2c95c2 in Sass::Eval::operator()(Sass::Map*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
(gdb) where
#0  0x00007fffee2c95c2 in Sass::Eval::operator()(Sass::Map*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#1  0x00007fffee2cb356 in Sass::Eval::operator()(Sass::List*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#2  0x00007fffee2d2d51 in Sass::Expand::operator()(Sass::Assignment*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#3  0x00007fffee2d7c94 in Sass::Expand::operator()(Sass::Import_Stub*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#4  0x00007fffee2d7c94 in Sass::Expand::operator()(Sass::Import_Stub*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#5  0x00007fffee2d7c94 in Sass::Expand::operator()(Sass::Import_Stub*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#6  0x00007fffee2d379c in Sass::Expand::operator()(Sass::Block*) ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#7  0x00007fffee29f7df in Sass::Context::compile() ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#8  0x00007fffee29ba3e in Sass::Data_Context::parse() ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#9  0x00007fffee273b27 in sass_compiler_parse ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#10 0x00007fffee2740e6 in sass_compile_data_context ()
   from /root/crap/myproject/node_modules/node-sass/vendor/linux-x64-48/binding.node
#11 0x000000000119519d in ?? ()
#12 0x00000000011a17c9 in ?? ()
#13 0x00007ffff701cb50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00007ffff6d66a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#15 0x0000000000000000 in ?? ()

Let me know if you need me to open an issue with LibSass, I'm not sure whether it belongs there...

Here is the reduced-test.zip. A simple npm install && npm start should trigger it.

[maddoger]

I have the same issue. Debian 7, node 6.7.0. Works only with 3.5.3 and below. On macOS all is ok with all versions.

[nschonni]

Seems like this might be related angular/components#1349. I'll see if I can reproduce, but it sounds like it might be a bad reference in Material somewhere along with an unfriendly error message from libsass

[netmikey]

Thanks for looking into this, @nschonni.
Wouldn't a bad reference in Material cause the compilation to also fail on macOS though?

[ghost]

I also have this problem, but only on my CI server running Debian 7 (32 bit).

me@my-machine$ node -v
v6.4.0
me@my-machine$ npm -v
3.10.3
me@my-machine$ npm ls | grep node-sass
│ ├─┬ node-sass@3.10.1

This bug is really annoying, since it only occurs on my CI server like I already said. This means that my whole development is currently on stop since I can't merge anything with builds not passing... Ubuntu 16.04 works just fine btw.

I am currently installing node-sass@3.5.3 as @maddoger suggested. I will update this comment as soon as I have results.

[emri99]

Got same problem on Debian wheezy x64 using webpack (only).
Followed @maddoger suggestion, it raises an Exception displaying error & stacktrace during build v8::Template::Set(v8::Local<v8::Name>, v8::Local<v8::Data>, v8::PropertyAttribute), but build completes.
Confirmed failing above node-sass@3.5.3, working below with stack trace
No problem on MacOS either.

Thanks @maddoger for this workaround before real fix.

[ghost]

I got the same errors as described by @emri99, but it seems to work now. Thanks @maddoger for this solution. Anyway, this workaround raises some other issues (for example I now have a huge verbose output for my CI builds because some C stacktraces seem to be appended to the node output... I don't know if this can cause other errrors either, but until now it seems to work).

But I suspect that this seems to be a Debian issue. Any ideas?

Edit: The other issues mentioned above now prevent my e2e tasks to complete. They run successfully, but the gulp task fails anyway...

[saper]

Can you try a simple reproduction from #1757 and see if that crashes for you?

[netmikey]

Thanks to @mgreter, I can confirm that recompiling node-sass after npm installing makes the subsequent webpack build work on both my Debian machines.

So the workaround for angular-cli/webpack users on Debian is to run the following after npm install:

cd node_modules/node-sass
node scripts/build -f
cd ../..

No need to use an old node-sass version anymore 🎉

[ghost]

I tried @netmikey's fix and can confirm that it works :) Thank you very much for sharing

[saper]

That's unfortunately not a solution, just a workaround...

[sagikazarmark]

Also, this requires python to be installed

[Pierstoval]

cd node_modules/node-sass
node scripts/build -f

Rebuilding the script worked for me, I have the same problem on a debian wheezy x64 server with latest node-sass version.

Even if it's just a workaround, not a solution 😕

[nschonni]

Can this be reproduced with 4.8.3?