Internal errors and segfaults when using "--watch"

[Misiur]

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ node -v
v7.10.1

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ npm -v
4.2.0

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ node -p process.versions
{ http_parser: '2.7.0',
  node: '7.10.1',
  v8: '5.5.372.43',
  uv: '1.11.0',
  zlib: '1.2.11',
  ares: '1.10.1-DEV',
  modules: '51',
  openssl: '1.0.2k',
  icu: '58.2',
  unicode: '9.0',
  cldr: '30.0.3',
  tz: '2016j' }

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ node -p process.platform
win32

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ node -p process.arch
x64

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ node -p "require('node-sass').info"
node-sass       4.5.3   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ ./node_modules/.bin/node-sass index.scss
.container {
  margin: auto; }

test@test-HP MINGW64 /d/Dev/private/react/sasscrash
$ ./node_modules/.bin/node-sass -w index.scss
=> changed: D:\Dev\private\react\sasscrash\index.scss
./node_modules/.bin/node-sass: line 14:  9068 Segmentation fault      node "$basedir/../node-sass/bin/node-sass" "$@"

Hello. I'm experiencing segfaults and internal errors ("Internal error: _some garbage characters_".) when using --watch flag. I'm running windows 7x64. File is saved with utf-8 encoding. I've tried rebuilding binary, crated a new project with fresh dependencies with the same results. I'm installing Visual studio right now, I've got .pdb files set up and I'll try to do the same steps as this user. I will update in this thread status of my investigation.

[Misiur]

This is what I get so far. I need to build node-sass in release mode to get ctx contents, is that correct?

[Misiur]

Ok, I've built in debug mode. Now this is interesting:

ctx in text form

-   ctx 0x0000000002d604c0 {type=SASS_CONTEXT_FILE (1) output_string=0x0000000000000000 <NULL> source_map_string=...} Sass_Context *
+   Sass_Options  {source_map_embed=false source_map_contents=false source_map_file_urls=false ...} Sass_Options
    type  SASS_CONTEXT_FILE (1) Sass_Input_Style
-   output_string 0x0000000000000000 <NULL> char *
      <Unable to read memory> char
-   source_map_string 0x0000000000000000 <NULL> char *
      <Unable to read memory> char
    error_status  3 int
-   error_json  0x0000000000000000 <NULL> char *
      <Unable to read memory> char
-   error_text  0x0000000002563fc0 "ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ" char *
      -35 'Ý' char
-   error_message 0x0000000002c2af40 "Internal Error: ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ\n" char *
      73 'I'  char
-   error_file  0x0000000000000000 <NULL> char *
      <Unable to read memory> char
    error_line  18446744073709551615  unsigned __int64
    error_column  18446744073709551615  unsigned __int64
-   error_src 0x0000000000000000 <NULL> const char *
      <Unable to read memory> const char
-   included_files  0x0000000000000000 {???}  char * *
      <Unable to read memory> char *

[Misiur]

Alright, after learning some cpp I've found where the error comes from:
https://github.com/sass/libsass/blob/4f74571d78d738ea5489d588550a26c81a45164b/src/sass_context.cpp#L141 Not really, I'll take a more thorough look

So it's a bug in libsass, however node-sass should not cause segfaults when sass_context_get_error_json returns empty value.

Just to be certain, my editor has atomic_save disabled.

[saper]

Thank you for your analysis! Could this have the same immediate cause like #2040 - libsass unable to produce working JSON on error involving encoding problems?

[Misiur]

I thought so, but it's not the case, because sometimes to trigger the error I have to change and save the file a few times (which is PITA in debugging it as I don't know if it's time to step into function or let it go further). Currently I'm dug in libsass, and I see really strange things:

[Misiur]

Ok, my last findings, I can't dig deeper without knowledge of C++ magic.
First, I was catching std::runtime_error, and got this:

Then I got to Sass::handle_error:

Here's the full e content:

-   e {...} stdext::exception & {std::runtime_error}
-   [std::runtime_error]  {...} std::runtime_error
-   std::exception  {_Data={_What=0x000000000266b860 "ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ" ...} }  std::exception
-   __vfptr 0x000007fed92a4208 {binding.node!void(* std::runtime_error::`vftable'[4])()} {0x000007fed8f32830 {binding.node!std::runtime_error::`scalar deleting destructor'(unsigned int)}, ...}  void * *
    [0] 0x000007fed8f32830 {binding.node!std::runtime_error::`scalar deleting destructor'(unsigned int)}  void *
    [1] 0x000007fed8f356c0 {binding.node!stdext::exception::what(void)} void *
-   _Data {_What=0x000000000266b860 "ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ" ...} __std_exception_data
-   _What 0x000000000266b860 "ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ" const char *
      -35 'Ý' const char
    _DoFree true (204)  bool

Something transforms std::runtime_error? I do not understand what is happening anymore, so I'll just leave this to better programmers.

[saper]

std::runtime_error is a result of an unhandled C++ exception. Great job!

[xzyfer]

This is probably fixed in 4.8.0