node-sass: Segmentation fault upon syntax error

I’m using grunt-sass to compile several files across my project. If there are no syntax errors, everything runs smoothly. If I run into a syntax error or any similar error, I encounter a segmentation fault. I’ve used node-segfault-handler to get the following log:

PID 25667 received SIGSEGV for address: 0x0
0   segfault-handler.node               0x0000000101ce91c8 _ZL16segfault_handleriP9__siginfoPv + 280
1   libsystem_platform.dylib            0x00007fff882e952a _sigtramp + 26
2   binding.node                        0x000000010893f9d8 _ZN4Sass15names_to_colorsE + 30520
3   binding.node                        0x0000000108825b45 _ZN4Sass13color_to_nameEd + 31
4   binding.node                        0x0000000108893522 _ZN4Sass7InspectclEPNS_5ColorE + 968
5   binding.node                        0x00000001088908fb _ZN4Sass7InspectclEPNS_11DeclarationE + 207
6   binding.node                        0x00000001088a035f _ZN4Sass6OutputclEPNS_7RulesetE + 1185
7   binding.node                        0x0000000108890383 _ZN4Sass7InspectclEPNS_5BlockE + 149
8   binding.node                        0x00000001088357d6 _ZN4Sass7Context6renderEPNS_5BlockE + 50
9   binding.node                        0x00000001088d2a7d sass_compiler_execute + 107
10  binding.node                        0x00000001088d2697 _Z20sass_compile_contextP12Sass_ContextPN4Sass7ContextE + 34
11  node                                0x000000010096e28a worker + 90
12  node                                0x000000010097a494 uv__thread_start + 25
13  libsystem_pthread.dylib             0x00007fff967e999d _pthread_body + 131
14  libsystem_pthread.dylib             0x00007fff967e991a _pthread_body + 0
15  libsystem_pthread.dylib             0x00007fff967e7351 thread_start + 13

The issue also seems connected to how many files or how many @import statements are being processed. If I move all the files out of the watched directories and leave just one file, it fails on syntax error just fine without a segfault. If I add two, three, four files with just a few imports, it’s still fine. But then I add another file with a lot of imports, and the segfault appears again. If I leave that last file where the segfault was just introduced, and I remove all the others, there’s no issue, so it doesn’t appear to be connected to particular files.

I’ve searched for solutions to this issue for a while but I’ve picked up on few patterns between the failures and none of the other Sass segfault solutions out there have worked. I’ve tried:

  • rm -rf node_modules && npm cache clear && npm install
  • Downgrading grunt-sass to previous versions (which track previous versions of node-sass)
  • Downgrading node to previous versions
  • Disabling sourcemaps

About this issue

  • Original URL
  • State: open
  • Created 8 years ago
  • Comments: 38 (25 by maintainers)

Commits related to this issue

Most upvoted comments

Could anyone with Mac OS X rebuild the binding with 'GCC_ENABLE_CPP_EXCEPTIONS': 'YES' instead and see if this continues to crash? cc @xzyfer

I think I did this right: clone, install, change that value in binding.gyp, build, npm link, verify it uses the correct binary by reading the output of npm rebuild node-sass in the target repo.

I don’t see a difference when using that binary.

Split out the parallel imports problem to #2789

The “race-condition” is probably just grunt-sass running multiple instances of render. It does an async forEach over the set of matched files. It’s probably one instance segfault’ing but the loop continues through the rest of the files.