Throwing error with a node-sass test on Windows

[am11]

@mgreter, @xzyfer

When running this test in node-sass should report correct sourceMap in stats with renderSync on windows, it throws this error:

  1) compile with stats should report correct sourceMap in stats with renderSync:
     Error: the string "Unable to allocate memory: bad allocation
" was thrown, throw an Error :)
      at Runner.fail (C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:196:11)
      at C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:455:16
      at done (C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runnable.js:206:5)
      at Test.Runnable.run (C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runnable.js:229:7)
      at Runner.runTest (C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:373:10)
      at C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:451:12
      at next (C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:298:14)
      at C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:308:7
      at next (C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:246:23)
      at Object._onImmediate (C:\Users\Adeel\Source\Repos\node-sass\node_modules\mocha\lib\runner.js:275:5)
      at processImmediate [as _immediateCallback] (timers.js:345:15)

I have tested further and it is working fine till this commit: f55b2d5. As soon as I try with the next commit (the last commit of v3.0.1): ca5f271, it throws the aforementioned error.

/cc @andrew

[am11]

Still getting this error with latest master: http://pastebin.com/meJj5pfn.

[xzyfer]

@am11 can you please provide the sassc cli command that spec runs, the input and expect output?

It'd be great if we could reproduce the error directly without node-sass.

[am11]

Hmm, that would be really difficult. I think stats is the node-sass only feature. It is implemented here: binding.cpp#L80-105. I am not sure if it is allocating memory incorrectly, or is it libsass' issue.

But further tests revealed that the issue weirdly only happen when call from the test. From node-sass interactive shell, the same works just fine:

C:\users\Adeel\Source\Repos\node-sass [master +1 ~1 -0 !]> cat C:\temp\foo.scss
// input
$test: (
  one: 1,
  two: 2,
);

$expect: (
  two: 2,
  one: 1,
);

.test {
  equal: $test == $expect;
}

C:\users\Adeel\Source\Repos\node-sass [master +1 ~1 -0 !]> node
> var stats = {};
undefined
> require("./sass").renderSync({
...   file: 'c:\\temp\\foo.scss',
...   stats: stats,
...   sourceMap: true
... });
'.test {\n  equal: true; }\n\n/*# sourceMappingURL=undefined.map */'
> stats.sourceMap.indexOf('foo.scss') !== -1
true
> stats
{ entry: 'c:\\temp\\foo.scss',
  start: 1414629548780,
  includedFiles: [ 'c:/temp/foo.scss' ],
  sourceMap: '{\n  "version": 3,\n  "file": "",\n  "sources": ["..\\/..\\/..\\/..\\/..\\/..\\/c:\\/temp\\/foo.scss"],\n
 "names": [],\n  "mappings": "AAWA,AACE,AAAO"\n}',
  end: 1414629548780,
  duration: 0 }

@kevva, can you provide any pointers for this?

[am11]

That undefined.scss in sourceMappingURL is also something we need to figure out in sass.js.

[xzyfer]

Thanks for your help @am11 . Apologies for my naivety I'm not familiar with either the sourcemaps implementation or node-sass so I'm trying to track down where the issue maybe it.

With this new information are you still certain the error was introduced in f55b2d5? Could it possibly be a sassc or node-sass issue?

[am11]

You don't have to apologize to be a C++ champ only! 😎

Till f55b2d5, it works fine:

git checkout f55b2d50342f97228a56a513b4cabf40996d6092
# then remove existing binary build, and then
node build
# followed by
npm test

it passes the stats test.

The next commit is ca5f271, which concluded v3.0.1. When I git checkout ca5f271883db61ccd1d1e1b84dd4830a2564896f, build and run test, it fails that test with error: Unable to allocate memory: bad allocation.

So the issue seems to be in ca5f271.

[xzyfer]

Hmm I annoyingly can't reproduce this on osx 👎

[mgreter]

@am11 maybe you can manually apply bits by bits of ca5f271 and compile again to see when this issue is triggered. Maybe it's that we are now passing ctx again to To_String to_string(&ctx);? I don't see why the introduction of the bool _skip_source_map_update should couse a crash!?

[am11]

Oh please disregard my previous comment. It didn't removed the existing binaries.

I have retested it and found the location of error.

diff --git a/output_nested.cpp b/output_nested.cpp
index 6ead1bf..7ca38dc 100644
--- a/output_nested.cpp
+++ b/output_nested.cpp
@@ -262,7 +262,8 @@ namespace Sass {
   void Output_Nested::append_to_buffer(const string& text)
   {
     buffer += text;
-    if (ctx) ctx->source_map.update_column(text);
+    if (ctx && !ctx->_skip_source_map_update)
+      ctx->source_map.update_column(text);
   }

Using if (ctx) // && !ctx->_skip_source_map_update) with rest of changes works fine. As soon as I use if (ctx && !ctx->_skip_source_map_update), it chokes. It also chokes with if (!ctx->_skip_source_map_update) but fails the test without throwing (gracefully) with if (ctx->_skip_source_map_update).

Apparently, it doesn't like ! there.. ❕ ❓

[am11]

Further diggings yielded; it's not the bool issue.

With this code:

void Output_Nested::append_to_buffer(const string& text)
{
    buffer += text;
//    ctx->source_map.update_column(text);
}

it throws the same exception, while this passes:

void Output_Nested::append_to_buffer(const string& text)
{
    buffer += text;
    ctx->source_map.update_column(text);
}

On x64 Windows with x86 node. On other x64 Windows with x64 node doesn't throw.

[mgreter]

I hope you don't mind, but I deleted the comment you said we can disregard . At least we now know that the issue is in the realm of the actual source map generating! I may can take a look at it tomorrow! But as @xzyfer already said, the source map generating is somehow a black box to us!

IMO it rather looks like the call to ctx->source_map.update_column(text); is needed. I don't think that the real culprit is the ! ctx->_skip_source_map_update check, or did you test that independenly? Maybe you can elaborate a bit more on your last comment, since I don't really get it why commenting out a line causes a crash!?

[am11]

@mgreter, yes that code was fine. Actually when the update_column isn't count, it sets garbage value for generated_position.line to size_t's max. That causes "string too long exception" at source_map.cpp#L73.

This is fixed by b6efc33 via #586.

[am11]

That makes perfect sense to delete that message. It constituted long lame outdated diffs anyway. :)

[mgreter]

Really great you could find the culprit, wasn't really in the mood the setup yet another compiler env :) Are you planning to add a PR to include appveyor for libsass? Because I think we could really benefit of a windows CI env!? This is somewhat on my todo list, but you may already got something working?

[am11]

Haven't made much progress there yet.

Actually I cloned this repository https://github.com/darrenkopp/libsass-net by @darrenkopp. It contains a .NET wrapper of libsass. I am planning to get a VS compatible make file out of it (or vcxproj file), so it works with Appveyor.

After that, we would have to do the same for sassc, to run the test. See sass/libsass-net@94abbd7#commitcomment-8333599.

I think we can have a vcxpro file in both repository, so anyone with VS2013 can just open the file and click the green play button to build libsass! 😄

[mgreter]

So lets shoutout to the libsass-net crew (@darrenkopp). Can you bless us with a CI config for appveyor, because you are probably the first ones to profit off of that :) The perl-libsass crew has this to show: http://matrix.cpantesters.org/?dist=CSS-Sass%20v3.0.1 ;)

[am11]

Going by vcxproj file (notice CICompile entires), it seems like they have configured their CI with VSO or some other TFS server. But it wouldn't be bad to have a free/publically-accessible one on Appveyor as well. 😄

[mgreter]

I guess this can be closed since #591 has been merged!
Please re-open if the problem still exists! Thanks!

[paynecodes]

I verified that node-sass seems to be referencing a a commit after #591 was merged, but still running into issues.

For example:

$svg-fills: (
  primary:      $primary-color,
  secondary:    $secondary-color,
  success:      $success-color,
  error:        $error-color
);

@each $fill in $svg-fills {
  .fill-#{$fill} { fill: map-get($svg-fills, $fill); }
}

Throws an error Unable to allocate memory: std::bad_alloc

Full error

gulp(17780,0x103f53000) malloc: *** mach_vm_map(size=7651461227091288064) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

stream.js:94
      throw er; // Unhandled stream error in pipe.
            ^
Error: Unable to allocate memory: std::bad_alloc

When I reduce the above map to just two values, it works. Anything over that, and it breaks.

$svg-fills: (
  primary:      $primary-color,
  secondary:    $secondary-color
);

[am11]

With new API, I get this error with your code:

{
        "status": 1,
        "path": "c:/temp/foo3.scss",
        "line": 2,
        "column": 17,
        "message": "unbound variable $primary-color"
}

[ngryman]

Hey,

I run into the same issue with nearly the same code as @jpdesigndev.
It seems to be related to maps manipulation in @each.
It's also random. Commenting, uncommenting chunks of codes make the issue disappear, re-appear randomly.