[DNM] CI Test

[mgreter]

Spec sass/sass-spec#720

Listing issues that only pass on some CI configurations:

• 1706: https://travis-ci.org/sass/libsass/jobs/103243294
  and https://travis-ci.org/sass/libsass/jobs/103243292
• parser/interpolate/25_escapes_single_quoted_specials/05_variable_quoted_double:
  https://travis-ci.org/sass/libsass/jobs/103492289
• parser/interpolate/24_escapes_double_quoted_specials/05_variable_quoted_double:
  https://travis-ci.org/sass/libsass/jobs/103492289

The last two seem related to #1786

[mgreter]

Seems we do have an issue with Appveyor MSVC Debug build. We should check how we can make the process not block when debug assertions are thrown (on spec for 1793):

[am11]

On R6010:

If we want to handle this in libsass, we would probably need to prevent the default std::terminate followed by abort (for example when application tries to write to memory outside its address space) by exception handling.

If we want to handle this in sassc, the C way, we would probably need to do error handling for Signals; we will catch SIGABRT as described under Example section of this article. However, literature-wise this article precedes the previous one.

[mgreter]

Sorry, forgot to mention I already merged sass/sassc@5cb56f3

[am11]

👍

[mgreter]

Now hunting down the issue which seems some memory corruption. Quite a hunt I can say so far ...
Basically we seem to have a buffer overflow somewhere, which corrupts that memory ... 🐛 🚑

[mgreter]

Issue is we pass a c_str() to Parser::from_c_str from a temporary when expanding Media Blocks.

[mgreter]

Added a fix to keep the memory alive until context is deleted. This exposes a funky issue with error reporting. We re-parse some things after ie. interpolation. An error there will not show the real source, but the interpolated thing we tried to re-parse (also note that the line number is off):

Error: 10in*px isn't a valid CSS value.
        on line 1 of spec/libsass-closed-issues/issue_1793/input.scss
>> (max-width: 10in*px)
   ------------^

Unsure how to handle this, best would be to be sure we don't error when we re-parse something (error on parse or after evaluation step, ie. with the above we could allow it to parse). I would like to remove all re-parse steps, since we should be able to evaluate the already parsed stuff directly.

Anyway, for now this seems to work ...

[mgreter]

@am11 I think we cannot prevent that popup in libsass directly, and somehow that makes sense. We don't know if the consumer is a GUI app or a console app, so the consumer should enforce that behavior. But I don't know how to apply this to ie. perl-libsass bindings for now. I actually wasn't able to include the statements I added in sassc directly into libsass, so I'm not even sure if we technically could enfore that from libsass side. Anyway this only seems to be related to debug builds, so I guess it doesn't make much sense to put too much effort into this.

[am11]

@mgreter, as a general practice, is the idea to handle exceptions in the LibSass for users and sanitize all the exceptions as compiler errors/warnings (for consistent experience)? It is probably a good idea to streamline exceptions in trans-compiler scenarios such as libsass. (however, this goes against the "principle of avoiding too much defensive programming" though.. 😄).

I actually wasn't able to include the statements I added in sassc directly into libsass

From C++ side, if _set_error_mode has no effect, we can try to suppress the dialog with SetErrorMode:

SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
_set_abort_behavior( 0, _WRITE_ABORT_MSG);