Webpack segmentation faults for newer versions of node-sass

[zg]

I've been getting segmentation faults from Webpack for a project I work on. From what I have read, the cause of these segfaults is due to the version of node-sass being beyond version 3.4.2. By downgrading or pinning to 3.4.2, people have mitigated the segfaulting from reoccurring.

In the case of the developer who downgraded from 3.5.2 to 3.4.2, there are a small number of changes that were made to node-sass between these versions. It might be easier to pinpoint the offending change, though I'm not familiar enough with Webpack's internals to pinpoint what changes could be causing these segfaults.

I am posting this here because the Webpack team has asked that I report it here instead.

[xzyfer]

Without a repeatable reproduction there isn't much we can do. There may have only been a few changes to the node-sass JS however there were many changes to LibSass C++ which the majority of this project's code.

[nschonni]

You've might have non-standard Sass and are being affected by the issues @xzyfer outlined in #1474

[xzyfer]

The other thing in play here is sass-loader which uses the importer API

[zg]

We've set up segfault-handler so we will be able to hopefully figure out the root cause. In the initial run of segfault-handler, we noticed issues with the node garbage collector, but I don't know what that says about the issue here.

[saper]

We also need more information: which OS is this, which node engine, and most important: the platform. Also getting a full log from processing may give us some hints. We are currently collecting information for a similar case with grunt: https://github.com/saper/sass_issue_1672 is a complete bug show case and #1672 contains some useful logs.

Can you supply us with the information similar to bug #1672 ?

[zg]

Operating system: OS X El Capitan 10.11.6 (15G31)
Node engine (assuming you meant version?): 4.5.0

I'm not sure what you mean by "platform". If you mean architecture, I'm on x86_64.

PID 84650 received SIGSEGV for address: 0xb
0   segfault-handler.node               0x00000001015f1fe8 _ZL16segfault_handleriP9__siginfoPv + 280
1   libsystem_platform.dylib            0x00007fff8a45352a _sigtramp + 26
2   ???                                 0x00000000fffffe31 0x0 + 4294966833
3   node                                0x00000001002cc070 _ZN2v88internal20MarkCompactCollector17EmptyMarkingDequeEv + 724
4   node                                0x00000001002898e5 _ZN2v88internal13GlobalHandles18IterateStrongRootsEPNS0_13ObjectVisitorE + 61
5   node                                0x00000001002aadbd _ZN2v88internal4Heap18IterateStrongRootsEPNS0_13ObjectVisitorENS0_9VisitModeE + 437
6   node                                0x00000001002cb937 _ZN2v88internal20MarkCompactCollector9MarkRootsEPNS0_18RootMarkingVisitorE + 27
7   node                                0x00000001002c6fc2 _ZN2v88internal20MarkCompactCollector15MarkLiveObjectsEv + 204
8   node                                0x00000001002c6ea0 _ZN2v88internal20MarkCompactCollector14CollectGarbageEv + 14
9   node                                0x000000010029fe0f _ZN2v88internal4Heap11MarkCompactEv + 107
10  node                                0x000000010029f161 _ZN2v88internal4Heap24PerformGarbageCollectionENS0_16GarbageCollectorENS_15GCCallbackFlagsE + 549
11  node                                0x000000010029ed05 _ZN2v88internal4Heap14CollectGarbageENS0_16GarbageCollectorEPKcS4_NS_15GCCallbackFlagsE + 419
12  node                                0x000000010029eaff _ZN2v88internal4Heap26CollectAllAvailableGarbageEPKc + 117
13  node                                0x0000000100270756 _ZN2v88internal7Factory19NewRawTwoByteStringEiNS0_13PretenureFlagE + 240
14  node                                0x00000001001702c6 _ZN2v88internal10JsonParserILb0EE18SlowScanJsonStringINS0_16SeqTwoByteStringEtEENS0_6HandleINS0_6StringEEES7_ii + 102
15  node                                0x000000010016d830 _ZN2v88internal10JsonParserILb0EE14ParseJsonValueEv + 114
16  node                                0x000000010016fb62 _ZN2v88internal10JsonParserILb0EE14ParseJsonArrayEv + 518
17  node                                0x000000010016d8e6 _ZN2v88internal10JsonParserILb0EE14ParseJsonValueEv + 296
18  node                                0x000000010016f008 _ZN2v88internal10JsonParserILb0EE15ParseJsonObjectEv + 896
19  node                                0x000000010016d8d9 _ZN2v88internal10JsonParserILb0EE14ParseJsonValueEv + 283
20  node                                0x000000010016d559 _ZN2v88internal10JsonParserILb0EE9ParseJsonEv + 207
21  node                                0x000000010041aaf6 _ZN2v88internal17Runtime_ParseJsonEiPPNS0_6ObjectEPNS0_7IsolateE + 285
22  ???                                 0x0000107cec10963b 0x0 + 18128722499131
23  ???                                 0x0000107cec2d4ec0 0x0 + 18128724381376
24  ???                                 0x0000107cec109ff7 0x0 + 18128722501623
25  ???                                 0x0000107cf11bb5d4 0x0 + 18128807114196
26  ???                                 0x0000107cf11ba461 0x0 + 18128807109729
27  ???                                 0x0000107cf11b8e4e 0x0 + 18128807104078
28  ???                                 0x0000107cf11b86ed 0x0 + 18128807102189

[saper]

Thank you. Looks like it crashes in code the node engine provides to the V8 garbage collector (similar issues). Having said that, we still cannot preclude that it is not node-sass or libsass fault, especially since we mix C++ runtime libraries on MacOS X, which is asking for trouble. As this happens during some JSON parsing by node it is also possible that node-sass is not involved here.

As per @bnoordhuis troubleshooting advice in nodejs/node#7654 can you try running node with --verify-heap? The next step would be to compile node from source by hand with debugging (./configure && make -C out BUILDTYPE=Debug), and trying again with --verify-heap as well.

[saper]

Another question: Did you try node-sass@3.8.0?

Also, it is very important to have a possibly small repository to reproduce this problem.

[zg]

The strangest part about the segfault issues we've been encountering is that they're not easy to reproduce. I was able to successfully do npm run build, but nothing was changed on the codebase.

Unfortunately, I cannot provide a repository which can reproduce this problem as we have written software that cannot be released publicly.

[zg]

I would also like to note that I installed node4-lts using brew.

[saper]

Since the exception occurs in the garbage collector it relies on some specific memory allocation pattern and some specific situation where garbage collection may be triggered. It would be interesting to see if the stacktraces are similar between crashes.

Please also try the newest node-sass code released (3.8.0). Also I'd recommend trying the same with node 6.x and see if the newer V8 engine somehow fixed or worked around the problem (even if the core cause is somewhere else). Please try building this on Linux/FreeBSD and see if you can reproduce this there.

Basically there are the following possibilities to continue troubleshooting this:

1. somebody by chance discovers a way to reproduce this without using your code
2. somebody finds the issue (V8/node/node-sass/libsass) independently
3. you are lucky with finding the cause with --verify-heap and/or debugger
4. you begin working on stripping your code down to the minimal reproduction case you can release publicly. Very often during the stripping process the issue becomes obvious or at least provides some cues (hey, "A" works, "B" doesn't).
5. you hire somebody to dig into your proprietary code base

[sunjay]

@saper I've found a case where a segmentation fault occurs. I don't know if it's the same as what was causing @zg's problem, but it consistently fails for me.

I believe I've found the minimum possible case. Anything left out of this causes a valid error message instead of a Segmentation fault.

Here's the SCSS:

:not(.something) {
  @extend .something;
  cursor: pointer;
}

The cursor property can be anything but must be there to cause the segmentation fault. I tried updating node-sass like you said and the segmentation fault still happens.

Before I deleted everything, .something was defined, so this isn't happening because that isn't there. Adding a definition for .something to the code above still results in Segmentation fault.

The :not() selector wasn't alone in my original code either. When I was deleting code I found that it doesn't really matter what the selector looks like so long as the .something in the :not() is the same as the argument to @extend.

$ ./node_modules/.bin/node-sass --version
node-sass   3.9.3   (Wrapper)   [JavaScript]
libsass     3.3.6   (Sass Compiler) [C/C++]
$ ./node_modules/.bin/node-sass segfault.scss
Segmentation fault

Edit: The code compiles file with just sass (though the version is different from the one reported above)

$ sass --version
Sass 3.4.21 (Selective Steve)
$ sass segfault.scss
:not(.something) {
  cursor: pointer; }

[zg]

Excellent find, @sunjay!

[saper]

This is great @sunjay. On my box it looks like the infinite loop that eats up all the memory.

[saper]

So, the good news is: this has been fixed in the current libsass master code:

m> ./bin/sassc -v
sassc: 3.3.6-11-g077a
libsass: 3.3.6-112-g6de5
sass2scss: 1.0.6
sass: 3.4
m> ./bin/sassc test.scss 
:not(.something) {
  cursor: pointer; }

[saper]

@zg I wonder how can we check if your issue is the same as the one @sunjay posted here

[zg]

Unfortunately I've since left the company and cannot see if this was the issue, though I have forwarded the comment by @sunjay to someone I know personally and he might look into it.

[saper]

I understand - I'll close the issue for now - if anyone comes up with a way to reproduce it, we can always reopen it. Thank you.

[sunjay]

@saper since this is fixed in the latest sass, do I just have to update my libsass version? Does node-sass use the system libsass version?

[saper]

@sunjay nope, if you use the binary file downloaded via npm install it includes a specific libsass version bundled with it. There is a way to build the binding with your own libsass, but you are on your own then.... We need a new libsass release (coming soon) and the next node-sass will usually follow shortly.