Sometimes the `sass_context_get_error_src` method returns an invalid pointer

[Taritsyn]

I am using the LibSass version 3.6.2. When compiling a large file (for example, modified _theming.scss file from the Angular Material package version 8.2.3), that contains a syntax error near the end of file, sass_context_get_error_src method may return an invalid pointer instead of the source code of this file.

[Taritsyn]

PR #3020 is a fix for this error.

[saper]

Do you know how to try to reproduce that problem?

[Taritsyn]

Take the _theming.scss file from the Angular Material package version 8.2.3 and remove the opening curly brace near the end of file. Then try compiling this file and during error handling try to read the value that returns the sass_context_get_error_src method.

This error occurred at once at two users of the LibSass Host for .NET library (see the “Unhandled exceptions” issue).

[mgreter]

AFAICT pstate.src should point to the same content you pass into libsass and it should live as long as the main context is alive. Any chance you could zip the code you've tested this with and attach it to this ticket? Also did you try it with sassc? What looks weird to me is that you take a copy when the error is handled, so the pointer still seems valid there. Any chance you take it from the context and dispose it earlier than the main context yourself?

Side note: in my refactoring branch I changed all char star pointers to be smart pointers, so they can easier outlive the main context if they are still used in some error object ...

[Taritsyn]

Also did you try it with sassc?

I haven't tried.

Any chance you take it from the context and dispose it earlier than the main context yourself?

Such a situation is excluded.

[mgreter]

So was able to reproduce this with LibSassHost and I've attached the file I used (rename the extension as github didn't allow scss directly). Now the good or bad news is that I tried this file also with sassc with address sanitizer enabled (clang 8.0.1 with -fsanitize=address) and it worked as expected ...

[saper]

What is interesting we copy pstate.src in some other place:

libsass/src/parser.cpp

Lines 2896 to 2897 in 4da7c4b

	// `pstate.src` may not outlive stack unwind so we must copy it.
	char *src_copy = sass_copy_c_string(pstate.src);

How long will parser state live in the exception handling?

[mgreter]

As long as you don't call sass_delete_context, that's the contract.

I played around a bit more, but lack the understanding how LibSassHost is structured. To reproduce I simply hijacked LibSassHost.Sample.Net4.ConsoleApp and figured that it uses ConsoleApp\bin\Release\x64\libsass.dll. Now I don't know exactly how this dll is compiled/produced, since the one in libsass\bin\Release\x64 is a lot smaller. And when I simply replace the one in the test console app with the smaller one from the libsass directory it actually starts to work!?