node-sass 4.8.1 crashes with WebPack running parallel compilation

[horaceleung]

We have been using "node-sass": "^4.5.3" in our package.json for some time now and since yesterday, we have been getting an error when run 'npm start'. Error below:

node(7981,0x70000b18c000) malloc: *** error for object 0x1041ac8b0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

However when we downgrade and fix the version to 4.5.3, we do not get the error anymore. ( without ^ to "node-sass": "4.5.3") so I am certain it is an issue caused by the latest version, possibly 4.8.1 ?

Please advice on this.

• NPM version (5.7.1)
• Node version (v8.10.0)
• Node Process ({ http_parser: '2.7.0',
  node: '8.10.0',
  v8: '6.2.414.50',
  uv: '1.19.1',
  zlib: '1.2.11',
  ares: '1.10.1-DEV',
  modules: '57',
  nghttp2: '1.25.0',
  openssl: '1.0.2n',
  icu: '60.1',
  unicode: '10.0',
  cldr: '32.0',
  tz: '2017c' }
  )
• Node Platform (darwin):
• Node architecture (x64)
• node-sass version (node-sass 4.8.1 (Wrapper) [JavaScript]
  libsass 3.5.0 (Sass Compiler) [C/C++])
• npm node-sass versions ( node-sass@4.8.1 ):

[xzyfer]

Are you able to provide some same code that produces this error? We can't debug this if we cannot reproduce it.

…

On 12 Mar. 2018 7:46 pm, "Horace Leung" ***@***.***> wrote: We have been using "node-sass": "^4.5.3" in our package.json for some time now and since yesterday, we have been getting an error when run 'npm start'. Error below: *node(7981,0x70000b18c000) malloc: *** error for object 0x1041ac8b0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug* However when we downgrade and fix the version to 4.5.3, we do not get the error anymore. ( without ^ to "node-sass": "4.5.3") so I am certain it is an issue caused by the latest version, possibly 4.8.1 ? Please advice on this. - NPM version (5.7.1) - Node version (v8.10.0) - Node Process ({ http_parser: '2.7.0', node: '8.10.0', v8: '6.2.414.50', uv: '1.19.1', zlib: '1.2.11', ares: '1.10.1-DEV', modules: '57', nghttp2: '1.25.0', openssl: '1.0.2n', icu: '60.1', unicode: '10.0', cldr: '32.0', tz: '2017c' } ) - Node Platform (darwin): - Node architecture (x64) - node-sass version (node-sass 4.8.1 (Wrapper) [JavaScript] libsass 3.5.0 (Sass Compiler) [C/C++]) - npm node-sass versions ( ***@***.*** ): — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2280>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWIob0aF9Qtjl68j46HjQ1O7OWt3Dks5tdjYAgaJpZM4SmQE7> .

[horaceleung]

This is our config, the issue is with sass-loader is not functioning and crashes with the mentioned error. If we remove sass-loader { loader: 'sass-loader' }, the error goes away. However we found the root cause was with node-sass latest version.

[chrishyle]

We are also experiencing this with a similar setup (darwin, node 8.9.4, webpack/sass-loader). Issue Started with 4.8.1; 4.7.2 works fine.

I regrettably cannot provide code.

[xzyfer]

Unfortunately we don't work with webpack so this config does not help us debug the issue.

Are you able to track down the actual Sass code that results in this error i.e. the specific @import that if you comment it out the error goes away.

[horaceleung]

Unfortunately I also can't provide my code but not sure if I can say which exact line causing it but I think this is a "general/overall' issue. All I know is that I downgrade to previous version and everything works.

[xzyfer]

I am also unable to reproduce this running the sass-loader test suite.
I'll keep digging but without a way to reproduce this our hands are tied.

[xzyfer]

Can you both confirm the version of webpack, and sass-loader you're using with the following:

$ npm ls webpack sass-loader

[horaceleung]

sass-loader@6.0.7

[joernroeder]

same here after i've updated from 4.7.2 to 4.8.1

─ sass-loader@6.0.7
─ webpack@3.11.0

[xzyfer]

Are you able to create a reproducible test case you can share? Without
actual Sass code there is no progress to be made here unfortunately.

I am unable to reproduce this my own, or some open source projects using
sass-loader.

Please do not comment with "me too"s.

You can subscribe to updates with the subscribe button -->

[xzyfer]

If anyone has time to help us debug this in real time, please join us in Slack.
https://libsass-slack.herokuapp.com/

[xzyfer]

Update: I've be blindly trying random github repos that use sass-loader in order to reproduce the issue. I have managed to stumble across one. Debugging the issue now.

[sloonz]

Tried to make a clean test case, but things got weird really fast: the bug goes away if I add delete options.importer; just before the actual call to node-sass (asyncSassJobQueue.push()), in sass-loader/lib/loader.js.

Stacktrace:

======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fb69e18abcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7fb69e190f96]
/lib/x86_64-linux-gnu/libc.so.6(+0x777de)[0x7fb69e1917de]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass9Functions9get_arg_rERKSsRNS_11EnvironmentINS_10SharedImplINS_8AST_NodeEEEEEPKcNS_11ParserStateEPNS_9BacktraceEdd+0x447)[0x7fb68dccd6c7]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass9Functions6darkenERNS_11EnvironmentINS_10SharedImplINS_8AST_NodeEEEEES6_RNS_7ContextEPKcNS_11ParserStateEPNS_9BacktraceESt6vectorINS2_INS_13Selector_ListEEESaISG_EE+0x14e)[0x7fb68dcdbd4e]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass4EvalclEPNS_13Function_CallE+0x3345)[0x7fb68dc8b375]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass6ExpandclEPNS_10AssignmentE+0xf8)[0x7fb68dc90ce8]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass6ExpandclEPNS_11Import_StubE+0x3f1)[0x7fb68dc965b1]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass6ExpandclEPNS_11Import_StubE+0x3f1)[0x7fb68dc965b1]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass6ExpandclEPNS_5BlockE+0x2f1)[0x7fb68dc95f01]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass7Context7compileEv+0x2fe)[0x7fb68dc4cd6e]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(_ZN4Sass12Data_Context5parseEv+0x37e)[0x7fb68dc47bce]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(sass_compiler_parse+0xe8)[0x7fb68dc0a258]
/home/dev/tmp/front/node_modules/node-sass/vendor/linux-x64-48/binding.node(sass_compile_data_context+0xa6)[0x7fb68dc0a886]
node[0x1320241]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7fb69e4c0494]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fb69e202aff]

[xzyfer]

Yes the issue is almost certainly related to custom importers (options.importer) since that's the bulks of what sass-loader does.

The reference to get_arg_r in that trace is interesting. There we some changes in that space. I'll investigate. Thanks

[sloonz]

Steps to reproduce, from a fresh project :

1. npm install webpack webpack-cli node-sass@4.8.1 sass-loader css-loader

for i in $(seq 1 1000) ; do echo '@import "common";' > style-$i.scss ; echo "require('./style-$i.scss');" >> app.js ; done

3. _common.scss :

$primaryHue: #272D42;
$primaryHue3: lighten($primaryHue, 8%);
$primaryHue2: darken($primaryHue, 8%);
$primaryHueDark: darken($primaryHue, 7%);

4. webpack.config.js :

module.exports = {
    entry: {
        app: './app.js'
    },
    module: {
        rules: [
            {
                test: /\.scss$/,
                loader: 'css-loader!sass-loader'
            },
        ]
    },
};

5. ./node_modules/.bin/webpack

Interesting points :

• The bug is random. If your reduce the number of require in app.js, it will sometimes pass. It sometimes won’t. Reducing it to one require ('stye-1.scss') makes it (almost ?) always pass.
• The size of _common.scss is also relevant.
• What _common.scss contains is relevant. I cannot trigger the bug with https://raw.githubusercontent.com/gpbl/material-ui-sass/master/material-ui/variables/_colors.scss, despite it being larger than my 4-lines _common.scss. Probably related to functions like lighten/darken ; it is indeed triggered when I add random lighten/darken calls in _colors.scss

[ronny332]

+1 @sloonz

Your description is identical with my findings, especially the random issues.
I'm using node-sass together with webpack and in 8 of 10 cases the webpack-dev-server dies with a segfault (double free). As it has a lot work to do in my case (one startup has to handle hundreds of scss files) the amount of crashes is for sure a lot higher than running the lib just for one file.

Downgrading to 4.7.2 solves the issue for now.

My system runs macOS 10.13.3. Using the default binary binding from npm ends in the crash as well as building it from source.

[xzyfer]

@sloonz thank you this is really helpful.

[xzyfer]

I'll need to head to bed shortly. The current work around is lock to node-sass@~4.7.

cc @mgreter this might be of interest to you. I ran some static analysis and nothing jumped out at me.

[xzyfer]

I've opened 2 separate (but likely related) upstream issues.

sass/libsass#2579
sass/libsass#2580

[xzyfer]

As a mitigation I've promoted 4.7.2 to latest. So future installs should now get it instead of 4.8.1.

For those wanting to dig around, 4.8.2 is available as node-sass@next.

[mgreter]

The issue is related to webpack/sass-loader running libsass compilers in parallel.
A temporarily way to circumvent it until a proper fix lands, is by calling webpack this way:
UV_THREADPOOL_SIZE=2 ./node_modules/.bin/webpack --mode development

[xzyfer]

Please try npm install node-sass@next to get the patched 4.8.2

[kartsims]

I am getting this issue with @rails/webpacker, here are the versions used :

• @rails/webpacker@3.5.5
• node-sass@^4.9.2
• sass-loader@^6.0.7
• webpack@^3.12.0

It happens when I add a new import statement in a .scss file. Is there a limitation to the number of import or something similar that trigger this error ?

[jakeNiemiec]

You would need to configure webpackER to even start handling this. The easiest solution is don't use webpackER to build your webpack config.