Error 3221225477 on Windows, trying to compile UTF-16 input file

[weaversam8]

Version Information:

• NPM version (5.1.0)
• Node version (v6.9.1)
• Node Process:

{ http_parser: '2.7.0',
  node: '6.9.1',
  v8: '5.1.281.84',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2j' }

• Node Platform (win32)
• Node architecture (x64)
• node-sass version:

node-sass       4.5.3   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]

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

`-- laravel-mix@0.12.1
  `-- node-sass@4.5.3

Problem Description:

I am using a third party library known as Laravel Mix to manage my webpack dependencies. I am compiling a file, known as app.scss, which has the import statement @import 'foundation' to import the Zurb Foundation library. Because the library is not immediately on my path, I'm using the node-sass feature of includePaths to add the path to the folder containing foundation.scss.

Upon running my code to compile, (by running the npm run dev script, which triggers webpack,) I reach the dependency of app.scss and then the process exits with the status of 3221225477. For the history of this error code, please see #1283. Unfortunately, I don't think this is a duplicate, because this isn't occurring on installation. I'd also like to add that I was unable to find a clear resolution or explanation of the problem in that thread, and would greatly appreciate someone explaining it to me in a simple manner if it's applicable.

Error Log:

The error log created by npm is here:

0 info it worked if it ends with ok
1 verbose cli [ 'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Users\\{username}\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'run',
1 verbose cli   'dev' ]
2 info using npm@5.1.0
3 info using node@v6.9.1
4 verbose run-script [ 'predev', 'dev', 'postdev' ]
5 info lifecycle @~predev: @
6 info lifecycle @~dev: @
7 verbose lifecycle @~dev: unsafe-perm in lifecycle true
8 verbose lifecycle @~dev: PATH: {path_redacted}
9 verbose lifecycle @~dev: CWD: C:\Users\{project_path}
10 silly lifecycle @~dev: Args: [ '/d /s /c', 'npm run development' ]
11 silly lifecycle @~dev: Returned: code: 3221225477  signal: null
12 info lifecycle @~dev: Failed to exec dev script
13 verbose stack Error: @ dev: `npm run development`
13 verbose stack Exit status 3221225477
13 verbose stack     at EventEmitter.<anonymous> (C:\Users\{username}\AppData\Roaming\npm\node_modules\npm\lib\utils\lifecycle.js:289:16)
13 verbose stack     at emitTwo (events.js:106:13)
13 verbose stack     at EventEmitter.emit (events.js:191:7)
13 verbose stack     at ChildProcess.<anonymous> (C:\Users\{username}\AppData\Roaming\npm\node_modules\npm\lib\utils\spawn.js:40:14)
13 verbose stack     at emitTwo (events.js:106:13)
13 verbose stack     at ChildProcess.emit (events.js:191:7)
13 verbose stack     at maybeClose (internal/child_process.js:877:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
14 verbose pkgid @
15 verbose cwd C:\Users\{project_path}
16 verbose Windows_NT 10.0.15063
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\{username}\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "run" "dev"
18 verbose node v6.9.1
19 verbose npm  v5.1.0
20 error code ELIFECYCLE
21 error errno 3221225477
22 error @ dev: `npm run development`
22 error Exit status 3221225477
23 error Failed at the @ dev script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 3221225477, true ]

Note the command line flags on line 10, which was an effort to try and put in place something mentioned in #1283, but it also failed.

[saper]

Thank you for a nice bug report!

This is Windows error C0000005 or ACCESS_VIOLATION which can be any kind of crash. Since you are not using Windows XP I also doubt it is any form of a duplicate.

What I am seeing here is an attempt to run npm run development from inside of npm run dev. I am not really sure this is related to node-sass at all.

Maybe downgrading npm might help but that's just guessing.

[weaversam8]

You are welcome! `npm run dev` is simply an alias to `npm run development` so that's what you're seeing there, but that doesn't have anything to do with the bug...

…

On Mon, Jul 10, 2017, 05:32 Marcin Cieślak ***@***.***> wrote: Thank you for a nice bug report! This is Windows error C0000005 or ACCESS_VIOLATION which can be any kind of crash. Since you are not using Windows XP I also doubt it is any form of a duplicate. What I am seeing here is an attempt to run npm run development from inside of npm run dev. I am not really sure this is related to node-sass at all. Maybe downgrading npm might help but that's just guessing.

[weaversam8]

To give some context, this is the scripts section of my package.json:

"scripts": {
    "dev": "npm run development",
    "development": "cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
    "watch": "cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --watch --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
    "watch-poll": "npm run watch -- --watch-poll",
    "hot": "cross-env NODE_ENV=development node_modules/webpack-dev-server/bin/webpack-dev-server.js --inline --hot --config=node_modules/laravel-mix/setup/webpack.config.js",
    "prod": "npm run production",
    "production": "cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
  }

[saper]

Sorry for my mistake!

[nschonni]

Can you reproduce this with just node-sass and without webpack?

[weaversam8]

Wasn't able to on a simple test case... scroll all the way down here for details: https://gist.github.com/weaversam8/1821e13947f61861e64683fdbab34721

Note that this was just node-sass, not just missing webpack but all the other tools I use to run my build.

[saper]

Maybe you need to add a custom importer you have mentioned in the comments?

[weaversam8]

@saper If you take a look, the custom importer is there and functioning.

[weaversam8]

Some updates:

• I changed the title because I realized I put the wrong error number in the title, not the body of the issue
• Turning of Windows Defender has no effect on the access violation.
• There was no visible uptake of RAM during the process, so I'm not really believing it's an out of memory error...

What's interesting is that this issue may be beginning to happen to others as well... 14 days ago was this: facebook/create-react-app#2661

Something from the original thread over at #1283: https://github.com/nodejs/node/blob/842e5a10ac59c826f875ef79e92d144e2655cc9a/test/common.js#L502-L505

[weaversam8]

What @gaearon said over in facebook/create-react-app#2661 is:

The specific symptom is that neither Yarn nor npm seem to be able to spawn a process.
I recommend you to file a bug with Node.js.

Does this jive with what you guys are seeing @saper @nschonni?

Interestingly enough, in the above referenced issue, I installed the packages that the OP of that issue did, and ran npm ls node-sass and it didn't bring up anything, signifying that this issue might not just be attached to node-sass.

[saper]

This needs to be verified if the process is not spawning:

1. that would mean something prevents us from doing so, for example resource limits like the heap size as suggested by one StackOverflow post.
   Not sure if Windows would use Access Violation for that (I don't know).

2. newly started node process aborts quickly using V8 facilities - v8::base::OS::abort() and V8_IMMEDIATE_CRASH

I understand that there is no reproduction case for us yet, right? Probably a reproduction case may require launching lots of parallel sass processors.

Next steps to find out what happens:

1. Observe processes using ProcExp (maybe difficult to spot, easier to track resources) and ProcMon and see what is spawned, how many and which proceses are launched and if there is some strain on resources.
2. Obtain debug symbols for node. If you can reproduce this problem also with node 6, then it's easier, since Need Debug Symbol (PDB) for Windows platform nodejs/node#5696 has been fixed in 6.x and later it is possible to download node.pdb files directly from nodejs.org. For older node engines this means building node from source by yourself to produce debug symbols.
3. Try to run node under debugger (cdb, ntsd, etc.) and obtain a stacktrace on abort() and see what's going on. There is a ProcDump utility that may help in obtaining a dump and a stacktrace upon certain conditions.

[weaversam8]

I'll see if I can get some of this to work. In addition, I'll see if I can get a minimum reproduction for you guys.

[weaversam8]

Preliminarily, I ran ProcExp, suspended the process before the error occurred, attached Visual Studio 2015, and then did manage to catch the error:

Keep in mind I'm new to debugging, so I'm not sure if what I've done next is accurate:

• I clicked Break, which launched into debugging, and complained about needing the symbols.
• I downloaded from nodejs.org the node.pdb file for node v6.9.1, and pointed VS to that.
• It loaded some information, then complained about not having a file named api.cc. I looked around after some googling, and found it in the nodejs/node repo under deps/v8/src.
• I then viewed the nodejs/node repository at the commit where v6.9.1 was tagged, and navigated to api.cc, which I then supplied.
• At this point, Visual Studio issued a warning about the file not matching a previous file? I didn't get the exact error text, but I went forward anyways, and this screen is my result:

Does any of this make any sense to you all?

I'm a web developer, I'm not used to dealing with this type of stuff, so I'm not sure how correct I am, but I'd love to learn!

[saper]

Very well done! Are you really using node 6.9.1 for this test? The exact version has to match.
The "Call Stack" is the backtrace I have asked for. To resolve "binding.node" stack frame (which comes from node-sass probably) - you can download the appropriate .pdb file from the node-sass releases page v4.5.3 for example - again it has to match your architecture (probably win32 x64) and node version 100%.

[saper]

If your call stack is correct, one explanation could be that a Sass error occurred, but we are getting null pointer from libsass sass_context_get_error_json() and that causes node to explode.

Setting a breakpoint before line 250 and getting the contents of the ctx structure might lead us somewhere.

Maybe you can also identify the problem in your Sass source, and this could be the simplest reproduction case.

[weaversam8]

I further tried to complicate my reproduction case by adding webpack and the vendor library I use to manage webpack, laravel-mix, to no avail. The next chance I get to run a full debug again, I'll see if I can resolve the binding.node stack frame, and see if I can set that breakpoint.

[weaversam8]

Further information about the bug:

Evidence suggests we've encountered a bug in V8. The function StringLength seen in my screenshot can be found in api.cc, and its source is:

inline int StringLength(const char* string) {
  return i::StrLength(string);
}

The function StrLength it calls has this source:

inline int StrLength(const char* string) {
   size_t length = strlen(string);
   ASSERT(length == static_cast<size_t>(static_cast<int>(length)));
   return static_cast<int>(length);
}

As you can see, calling this function with a null pointer gives the crash in question.

I filed a bug report with V8 here: https://groups.google.com/forum/#!topic/v8-dev/e240zonwV3g

As I understand it, I don't think this is the real root of the problem I'm experiencing, but I think we found a bug in V8 in the process... I think finding the files for that binding.node frame should help get to the root of the bug in the JS as well. I wasn't immediately clear about which version of the binding.node to download, but I hope to figure it out soon.

[saper]

@weaversam8 It is not a bug in V8. Zero is an illegal argument for this function and crashing is unfortunately the expected response. We need to find out the contents of the ctx variable inside of libsass sass_context_get_error_json() function.

The error coming out of Sass processing did not get converted to JSON properly. I really would like to know what kind of error is this. I hope this is not some resource constraint, really.

We also need code to reproduce this bug.

Check the node-sass/vendor directory your binding.node is in. A subdirectory will be prefixed with the platform/API prefix, which corresponds to the binding.node names on our site. You shouldn't need to download binding.node, just get the matching PDB file.

Also checkout the sources of node-sass for your version (use tags) from git, and use subst to make sure they are accessible under S:\node_modules\node-sass. This will help VisualStudio to find them automatically.

A similar trick should work for node sources (no longer pointing to api.cc by hand) but I don't know the directory where the source should be stored (but VS can be certainly told to look somewhere else as well).

[weaversam8]

Got it. Which version of the sass bindings should I download. I saw many win32 x64 bindings, all with a different number after them...

[saper]

Which one do you have installed in your node-sass vendor folder?

I have for example

vendor/freebsd-x64-11/binding.node

which means I have a binding file for FreeBSD amd64 for node 0.10 installed. You will certainly have win32-something.

[weaversam8]

@saper you were right, it was with sass_context_get_error_json. After loading up the binding.node file for node-sass, I found myself in the MakeCallback function.

Contents of ctx, as requested. It's giving me a little more insight into the error 😄

Do you know where the problem is in node-sass?

[weaversam8]

My Problem Explanation

I discovered that this was a simple case of node-sass trying to compile a UTF-16 file instead of UTF-8. Changing the text encoding of the file fixed my issue and allowed my code to run.

Remaining Problem

I'm not exactly clear why node-sass failed to provide a proper error message, but that's what's still left to figure out. Ideally we can reproduce a test case now by trying to compile a UTF-16 file?

[saper]

Can you post the ctx variable as text?

Can you build a simple replication case with UTF-16?

[weaversam8]

Here's a replication case. Run npm install in this directory to install the dependencies, then try running npm run dev

issue-2040.zip

Edit: I'm not sure how to get the ctx variable as text.

[weaversam8]

@davidhantson as I understand it this is an issue in the underlying C code. There should never be any input to node-sass that should cause the low level code to error but it does. Theoretically every error should be returned in some form or another to the Javascript interface, but it isn't in this case which is what this issue should be focused on: fixing the error delivery path from the low level code all the way up to the Javascript.

The underlying issue that caused this error, my error at least, was an input file to node-sass being in an encoding other than UTF-8 (UTF-16 in my case.) Are you sure all the input files are UTF-8?

[gangsthub]

Did you upgraded node after installing your dependencies? I'd recommend to run our good old friend:

rm -rf ./node_modules
npm i

And try again. See rimraf if you don't have the command rm. ;)

[mikaelvinicius]

I fix this issue just unistalling npm most recent and download the recommended on npm website

[saper]

Since there is not much to be done in this bug report, closing.