Sometimes the `sass_context_get_error_src` method returns an invalid pointer #3019

Taritsyn · 2019-10-29T12:56:31Z

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.

The text was updated successfully, but these errors were encountered:

Taritsyn · 2019-10-29T13:27:55Z

PR #3020 is a fix for this error.

saper · 2019-10-29T13:32:21Z

Do you know how to try to reproduce that problem?

Taritsyn · 2019-10-29T13:47:04Z

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 · 2019-10-29T14:02:03Z

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 · 2019-10-29T14:11:02Z

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 · 2019-10-29T16:41:43Z

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 · 2019-10-29T17:41:22Z

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 · 2019-10-29T17:46:35Z

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!?

saper · 2019-10-29T18:26:00Z

One dangerous thing:

libsass/src/parser.cpp

Line 2900 in 4da7c4b

throw Exception::InvalidSass(pstate, traces, msg, src_copy);

pstate here lives on local stack and is passed over as the argument to the exception

glebm · 2019-10-29T18:33:28Z

That's why we copy src there. Basically we should copy it whenever it is not a pointer to the original source (which is the only string that lives long enough). pstate itself is just a few ints and a char* pointer.

saper · 2019-10-29T18:44:22Z

Does it help if pstate.src was good but pstate got overwritten? Maybe it is irrelevant here since in that case even #3019 couldn't help (pstate.src would have been corrupted at the time we try to copy it).

saper · 2019-10-29T18:49:06Z

We release owned_src (the string we copied in

libsass/src/parser.cpp

Line 2900 in 4da7c4b

throw Exception::InvalidSass(pstate, traces, msg, src_copy);

in the destructor

libsass/src/error_handling.hpp

Line 56 in 4da7c4b

virtual ~InvalidSass() throw() { sass_free_memory(owned_src); };

mgreter · 2019-10-29T18:54:03Z

I guess saper is right, a few simple prints seem to confirm this.

mgreter · 2019-10-29T19:10:29Z

@glebm do you remember why you added owned_src? It seems to violate the contract that the memory will live as long as the main context. The error object will be gone once consumers want to access it on the context and it will delete whatever c_ctx->error_src points to with it.

For a quick fix we might get away by stealing the owned_src from the error object:

c_ctx->error_src = e.pstate.src;
+ e.owned_src = 0;

But I wonder why we make a copy in the first place ...

glebm · 2019-10-29T19:39:06Z

We release owned_src (the string we copied in

@saper @mgreter Before that happens, we clear owned src in the copy constructor (ownership transfer):

libsass/src/error_handling.hpp

Lines 44 to 47 in f7567ea

    
           InvalidSass(InvalidSass& other) : Base(other), owned_src(other.owned_src) { 
        
             // Assumes that `this` will outlive `other`. 
        
             other.owned_src = nullptr; 
        
           }

This should really be a move-only type, but VS2013 doesn't fully support that (not an issue here though).

But I wonder why we make a copy in the first place ...

IIRC it's because src doesn't always point to the original source: sometimes it points to a copy of a part of the source / partially processed source that will be destroyed before the context. See the original bug #2643

mgreter · 2019-10-29T19:44:33Z

OK, stepped through all life-cycles and the issue we have at hand is the following.
So the problem is that we release the cpp context on delete_compiler. So to speak the c context (note that we have a cpp and a c-api context) outlives the cpp context (which makes sense). I believe the fix by @Taritsyn is correct and that it makes the owned_src obsolete, since the error object should still be around when we copy stuff from cpp context to c context.

glebm · 2019-10-29T19:44:44Z

@saper Basically I think what you're likely seeing is a similar issue but not for InvalidSass. Have you checked the error type and origin with a debugger?
Perhaps it's a different error type that needs similar treatment to InvalidSass.

glebm · 2019-10-29T19:45:41Z

Whatever you do please test with https://github.com/sass/libsass/files/1965545/case.zip and ASAN to avoid a regression.

mgreter · 2019-10-29T19:47:26Z

Sure, please check it too once I have the PR ready

glebm · 2019-10-29T19:51:18Z

@mgreter Here is an example where we parse a temporary string not attached to the context:

libsass/src/fn_utils.cpp

Lines 132 to 134 in 23cabbe

    
             std::string exp_src = exp->to_string(ctx.c_options); 
        
             return Parser::parse_selector(exp_src.c_str(), ctx, traces, exp->pstate(), pstate.src, /*allow_parent=*/false); 
        
           }

If this throws and we don't copy, the src pointer in the exception will point to freed memory as soon as this stack unwinds.

There are probably other places where this happens:

git grep 'Parser::' | grep -v '^src/parser[._]'

mgreter · 2019-10-29T19:57:43Z

Thanks, these should probably go into ctx.strings.push_back(...) for lack of any smarter way.

Fixes sass#3019

mgreter · 2019-10-29T20:44:11Z

After some more thoughts I'll leave the fix by @Taritsyn as is (#3022), just added some more missing bits. Since I already addressed some of the underlying issues in my upcoming branch I will leave it this way. Also since there is only some minor overhead and only in error cases with this solution. In the future I want to use smart pointers for content references and I also created a class that will allow to mix evaluated parts into the real/parent style-sheet in order to report dynamic cases even better.

Taritsyn · 2019-10-29T21:16:33Z

@mgreter

Now I don't know exactly how this dll is compiled/produced, since the one in libsass\bin\Release\x64 is a lot smaller.

Assemblies are built using two scripts: build-libsass.cmd (for Windows) and build-libsass.sh (for Linux and OSX). Script for Windows is run from the Developer Command Prompt for VS 2019 with the --embed-msvc-runtime argument. Then assemblies is manually copied to appropriate subdirectories of the lib directory. After that are create NuGet packages by building LibSassHost.Native.* projects. Created packages are automatically copied to the nuget directory.

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!?

It is better to install assembly in the form of NuGet package. In this case, NuGet package will copy the assembly by using MSBuild (see the LibSassHost.Native.win-x86.props and LibSassHost.Native.win-x64.props files) to subdirectory of the bin directory.

saper · 2019-10-30T00:18:43Z

@saper @mgreter Before that happens, we clear owned src in the copy constructor (ownership transfer):

I have added some crazy debugging https://gist.github.com/48ff78d712a17d8936635dd6636ffcde and the result is:

InvalidSass instantiated, pstate is 0x7fffffffd260 owned_src is 0x80126f500
InvalidSass destroyed, owned_src was 0x80126f500
Error: Invalid CSS after "...l-theme($theme)": expected "{", was "@include mat-core-t"
        on line 5033:37 of libsass-host-issue.scss
>> @mixin angular-material-theme($theme)

   ------------------------------------^

Seems like there is just one instance we are passing around...

saper · 2019-10-30T00:46:06Z

But you are right about pstate - it gets copied around to the exception handler, which see a new ins
stance on the parameter stack that is different than the one originally created:

(running version patched with https://gist.github.com/48ff78d712a17d8936635dd6636ffcde so line numbers are slightly off)

gdb831 --args /home/saper/sw/libsass/sassc/bin/sassc libsass-host-issue.scss
GNU gdb (GDB) 8.3.1 [GDB v8.3.1 for FreeBSD]
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/saper/sw/libsass/sassc/bin/sassc...
(gdb) break error_handling.cpp:24
Breakpoint 1 at 0x3d3b60: file error_handling.cpp, line 24.
(gdb) break parser.cpp:2897
Breakpoint 2 at 0x33170c: file parser.cpp, line 2897.
(gdb) run
Starting program: /home/saper/sw/libsass/sassc/bin/sassc libsass-host-issue.scss

Breakpoint 2, Sass::Parser::error (this=0x7fffffffdf60, 
    msg="Invalid CSS after \"...l-theme($theme)\": expected \"{\", was \"@include mat-core-t\"", pos=...)
    at parser.cpp:2897
2897	    char *src_copy = sass_copy_c_string(pstate.src);
(gdb) info frame
Stack level 0, frame at 0x7fffffffd450:
 rip = 0x33170c in Sass::Parser::error (parser.cpp:2897); saved rip = 0x303ec0
 called by frame at 0x7fffffffd5e0
 source language c++.
 Arglist at 0x7fffffffd440, args: this=0x7fffffffdf60, 
    msg="Invalid CSS after \"...l-theme($theme)\": expected \"{\", was \"@include mat-core-t\"", pos=...
 Locals at 0x7fffffffd440, Previous frame's sp is 0x7fffffffd450
 Saved registers:
  rbx at 0x7fffffffd418, rbp at 0x7fffffffd440, r12 at 0x7fffffffd420, r13 at 0x7fffffffd428,
  r14 at 0x7fffffffd430, r15 at 0x7fffffffd438, rip at 0x7fffffffd448
(gdb) print pstate
$1 = {<Sass::Position> = {<Sass::Offset> = {line = 5032, column = 36}, file = 0}, 
  path = 0x8009af240 "/home/saper/sw/issue-3019/libsass-host-issue.scss", 
  src = 0x8009b0c40 "\357\273\277// Import all the theming functionality.\n// We can use relative imports for imports from the cdk because we bundle everything\n// up into a single flat scss file for material.\n// We want overlays to"..., offset = {line = 0, column = 0}, token = {prefix = 0x0, begin = 0x0, end = 0x0}}
(gdb) print &pstate
$2 = (Sass::ParserState *) 0x7fffffffd388
(gdb) next
2898	    pstate.src = src_copy;
(gdb) print src_copy
$3 = 0x80126f500 "\357\273\277// Import all the theming functionality.\n// We can use relative imports for imports from the cdk because we bundle everything\n// up into a single flat scss file for material.\n// We want overlays to"...
(gdb) info local
pstate = {<Sass::Position> = {<Sass::Offset> = {line = 5032, column = 36}, file = 0}, 
  path = 0x8009af240 "/home/saper/sw/issue-3019/libsass-host-issue.scss", 
  src = 0x8009b0c40 "\357\273\277// Import all the theming functionality.\n// We can use relative imports for imports from the cdk because we bundle everything\n// up into a single flat scss file for material.\n// We want overlays to"..., offset = {line = 0, column = 0}, token = {prefix = 0x0, begin = 0x0, end = 0x0}}
p = {<Sass::Offset> = {line = 5032, column = 36}, file = 0}
src_copy = 0x80126f500 "\357\273\277// Import all the theming functionality.\n// We can use relative imports for imports from the cdk because we bundle everything\n// up into a single flat scss file for material.\n// We want overlays to"...
(gdb) next
2899	    traces.push_back(Backtrace(pstate));
(gdb) cont
Continuing.

Breakpoint 1, Sass::Exception::InvalidSass::InvalidSass (this=0x801298080, pstate=..., traces=..., msg=..., 
    owned_src=0x80126f500 "\357\273\277// Import all the theming functionality.\n// We can use relative imports for imports from the cdk because we bundle everything\n// up into a single flat scss file for material.\n// We want overlays to"...) at error_handling.cpp:24
24		fprintf(stderr, "InvalidSass instantiated, pstate is %p owned_src is %p\n",
(gdb) info frame
Stack level 0, frame at 0x7fffffffd240:
 rip = 0x3d3b60 in Sass::Exception::InvalidSass::InvalidSass (error_handling.cpp:24); saved rip = 0x331903
 called by frame at 0x7fffffffd450
 source language c++.
 Arglist at 0x7fffffffd230, args: this=0x801298080, pstate=..., traces=..., msg=..., 
    owned_src=0x80126f500 "\357\273\277// Import all the theming functionality.\n// We can use relative imports for imports from the cdk because we bundle everything\n// up into a single flat scss file for material.\n// We want overlays to"...
 Locals at 0x7fffffffd230, Previous frame's sp is 0x7fffffffd240
 Saved registers:
  rbx at 0x7fffffffd210, rbp at 0x7fffffffd230, r12 at 0x7fffffffd218, r14 at 0x7fffffffd220,
  r15 at 0x7fffffffd228, rip at 0x7fffffffd238
(gdb) print &pstate
$4 = (Sass::ParserState *) 0x7fffffffd240
(gdb) print pstate
$5 = {<Sass::Position> = {<Sass::Offset> = {line = 5032, column = 36}, file = 0}, 
  path = 0x8009af240 "/home/saper/sw/issue-3019/libsass-host-issue.scss", 
  src = 0x80126f500 "\357\273\277// Import all the theming functionality.\n// We can use relative imports for imports from the cdk because we bundle everything\n// up into a single flat scss file for material.\n// We want overlays to"..., offset = {line = 0, column = 0}, token = {prefix = 0x0, begin = 0x0, end = 0x0}}
(gdb)

So pstate gets copied on stack from 0x7fffffffd388 to 0x7fffffffd240 as it should, a shallow copy that keeps path and the copied src on heap.

saper · 2019-10-30T02:17:49Z

Here's more:

We could not reproduce this problem because sassc never calls sass_context_get_error_src()... with this patch:

diff --git a/sassc.c b/sassc.c
index dcb3fff..29a2279 100644
--- a/sassc.c
+++ b/sassc.c
@@ -53,10 +53,11 @@ int get_argv_utf8(int* argc_ptr, char*** argv_ptr) {
 #include <sysexits.h>
 #endif
 
-int output(int error_status, const char* error_message, const char* output_string, const char* outfile) {
+int output(int error_status, const char* error_message, const char *error_src, const char* output_string, const char* outfile) {
     if (error_status) {
         if (error_message) {
             fprintf(stderr, "%s", error_message);
+            fprintf(stderr, "error_src: %s", error_src);
         } else {
             fprintf(stderr, "An error occurred; no error message available.\n");
         }
@@ -139,6 +140,7 @@ int compile_stdin(struct Sass_Options* options, char* outfile) {
     ret = output(
         sass_context_get_error_status(ctx_out),
         sass_context_get_error_message(ctx_out),
+        sass_context_get_error_src(ctx_out),
         sass_context_get_output_string(ctx_out),
         outfile
     );
@@ -160,6 +162,7 @@ int compile_file(struct Sass_Options* options, char* input_path, char* outfile)
     ret = output(
         sass_context_get_error_status(ctx_out),
         sass_context_get_error_message(ctx_out),
+        sass_context_get_error_src(ctx_out),
         sass_context_get_output_string(ctx_out),
         outfile
     );
@@ -168,6 +171,7 @@ int compile_file(struct Sass_Options* options, char* input_path, char* outfile)
         ret = output(
             sass_context_get_error_status(ctx_out),
             sass_context_get_error_message(ctx_out),
+            sass_context_get_error_src(ctx_out),
             sass_context_get_source_map_string(ctx_out),
             srcmap_file
         );

After this, it crashes nicely - here is the output of the testcase from @glebm #3019 (comment)

This is pure 3.6.2 configured with

 env CC=clang90 CXX=clang++90 CFLAGS='-g -fsanitize=address -fno-omit-frame-pointer' CXXFLAGS='-g -fsanitize=address -fno-omit-frame-pointer' ./configure

(sassc was built in a similar way, I have used clang++90 as a linker)

Error: Invalid CSS after "&": expected selector, was "�hover lrgba(100, 1"
        on line 1:1 of [SELECTOR], in function `selector-nest`
        from line 3:15 of SESSION000:id:000072,sig:06,src:004062,op:flip1,pos:50
>> &�hover lrgba(100, 120, 140, #5)i
   ^
=================================================================
==16072==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000002b10 at pc 0x0000003015d3 bp 0x7fffffffe760 sp 0x7fffffffdee8
READ of size 2 at 0x604000002b10 thread T0
    #0 0x3015d2 in printf_common(void*, char const*, __va_list_tag*) /wrkdirs/usr/ports/devel/llvm90/work/compiler-rt-9.0.0.src/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:547:9
    #1 0x3023ff in __interceptor_vfprintf /wrkdirs/usr/ports/devel/llvm90/work/compiler-rt-9.0.0.src/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1637:1
    #2 0x3023ff in fprintf /wrkdirs/usr/ports/devel/llvm90/work/compiler-rt-9.0.0.src/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1694
    #3 0x368a68 in output /home/saper/sw/libsass/sassc/sassc.c:60:13
    #4 0x36900e in compile_file /home/saper/sw/libsass/sassc/sassc.c:162:11
    #5 0x369971 in main /home/saper/sw/libsass/sassc/sassc.c:374:18
    #6 0x2e411a in _start /usr/src/lib/csu/amd64/crt1.c:76:7

0x604000002b10 is located 0 bytes inside of 34-byte region [0x604000002b10,0x604000002b32)
freed by thread T0 here:
    #0 0x33b6cd in free /wrkdirs/usr/ports/devel/llvm90/work/compiler-rt-9.0.0.src/lib/asan/asan_malloc_linux.cc:123:3
    #1 0x58e487 in Sass::Exception::InvalidSass::~InvalidSass() /home/saper/sw/libsass/src/./error_handling.hpp:56:42
    #2 0x8009d8135 in __cxa_free_exception /usr/src/contrib/libcxxrt/exception.cc:627:4
    #3 0x8009d8135 in releaseException(__cxxabiv1::__cxa_exception*) /usr/src/contrib/libcxxrt/exception.cc:652
    #4 0x8009d8135 in __cxa_end_catch /usr/src/contrib/libcxxrt/exception.cc:1352
    #5 0x526fe0 in sass_compile_context(Sass_Context*, Sass::Context*) /home/saper/sw/libsass/src/sass_context.cpp:317:7
    #6 0x368fcd in compile_file /home/saper/sw/libsass/sassc/sassc.c:160:5
    #7 0x369971 in main /home/saper/sw/libsass/sassc/sassc.c:374:18
    #8 0x2e411a in _start /usr/src/lib/csu/amd64/crt1.c:76:7
    #9 0x8008d8fff  (<unknown module>)

previously allocated by thread T0 here:
    #0 0x33b83d in malloc /wrkdirs/usr/ports/devel/llvm90/work/compiler-rt-9.0.0.src/lib/asan/asan_malloc_linux.cc:145:3
    #1 0x36a460 in sass_alloc_memory /home/saper/sw/libsass/src/sass.cpp:39:17
    #2 0x36a460 in sass_copy_c_string /home/saper/sw/libsass/src/sass.cpp:50:25
    #3 0x668015 in Sass::Parser::error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Sass::Position) /home/saper/sw/libsass/src/parser.cpp:2897:22
    #4 0x5a82ab in Sass::Parser::error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) /home/saper/sw/libsass/src/parser.cpp:2905:5
    #5 0x5a82ab in Sass::Parser::css_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool) /home/saper/sw/libsass/src/parser.cpp:2976:5
    #6 0x5fb4c9 in Sass::Parser::parse_simple_selector() /home/saper/sw/libsass/src/parser.cpp:704:7
    #7 0x6a0be9 in Sass::Parser::parseCompoundSelector() /home/saper/sw/libsass/src/parser_selectors.cpp:169:33
    #8 0x69e09b in Sass::Parser::parseComplexSelector(bool) /home/saper/sw/libsass/src/parser_selectors.cpp:42:47
    #9 0x6a36dc in Sass::Parser::parseSelectorList(bool) /home/saper/sw/libsass/src/parser_selectors.cpp:82:36
    #10 0x5a11ea in Sass::Parser::parse_selector(char const*, Sass::Context&, std::__1::vector<Sass::Backtrace, std::__1::allocator<Sass::Backtrace> >, Sass::ParserState, char const*, bool) /home/saper/sw/libsass/src/parser.cpp:66:14
    #11 0x84ac78 in Sass::Functions::selector_nest(Sass::Environment<Sass::SharedImpl<Sass::AST_Node> >&, Sass::Environment<Sass::SharedImpl<Sass::AST_Node> >&, Sass::Context&, char const*, Sass::ParserState, std::__1::vector<Sass::Backtrace, std::__1::allocator<Sass::Backtrace> >&, std::__1::vector<Sass::SharedImpl<Sass::SelectorList>, std::__1::allocator<Sass::SharedImpl<Sass::SelectorList> > >, std::__1::vector<Sass::SharedImpl<Sass::SelectorList>, std::__1::allocator<Sass::SharedImpl<Sass::SelectorList> > >) /home/saper/sw/libsass/src/fn_selectors.cpp:39:31
    #12 0x6d82ef in Sass::Eval::operator()(Sass::Function_Call*) /home/saper/sw/libsass/src/eval.cpp:1058:18
    #13 0x6c49ae in Sass::Eval::operator()(Sass::Binary_Expression*) /home/saper/sw/libsass/src/eval.cpp:735:16
    #14 0x6beafe in Sass::Eval::operator()(Sass::List*) /home/saper/sw/libsass/src/eval.cpp:509:27
    #15 0x6bbc9b in Sass::Eval::operator()(Sass::Debug*) /home/saper/sw/libsass/src/eval.cpp:430:42
    #16 0x715c09 in Sass::Debug::perform(Sass::Operation<Sass::Expression*>*) /home/saper/sw/libsass/src/./ast.hpp:687:5
    #17 0x715c09 in Sass::Expand::operator()(Sass::Debug*) /home/saper/sw/libsass/src/expand.cpp:462:8
    #18 0x72d953 in Sass::Expand::append_block(Sass::Block*) /home/saper/sw/libsass/src/expand.cpp:838:32
    #19 0x70155b in Sass::Expand::operator()(Sass::Block*) /home/saper/sw/libsass/src/expand.cpp:140:11
    #20 0x551f2a in Sass::Context::compile() /home/saper/sw/libsass/src/context.cpp:650:12
    #21 0x54f593 in Sass::File_Context::parse() /home/saper/sw/libsass/src/context.cpp:579:12
    #22 0x52787f in Sass::sass_parse_block(Sass_Compiler*) /home/saper/sw/libsass/src/sass_context.cpp:180:31
    #23 0x52787f in sass_compiler_parse /home/saper/sw/libsass/src/sass_context.cpp:434:22
    #24 0x526fe0 in sass_compile_context(Sass_Context*, Sass::Context*) /home/saper/sw/libsass/src/sass_context.cpp:317:7
    #25 0x368fcd in compile_file /home/saper/sw/libsass/sassc/sassc.c:160:5
    #26 0x369971 in main /home/saper/sw/libsass/sassc/sassc.c:374:18
    #27 0x2e411a in _start /usr/src/lib/csu/amd64/crt1.c:76:7
    #28 0x8008d8fff  (<unknown module>)

SUMMARY: AddressSanitizer: heap-use-after-free /wrkdirs/usr/ports/devel/llvm90/work/compiler-rt-9.0.0.src/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:547:9 in printf_common(void*, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
  0x4c0800000510: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x4c0800000520: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x4c0800000530: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x4c0800000540: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x4c0800000550: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
=>0x4c0800000560: fa fa[fd]fd fd fd fd fa fa fa fd fd fd fd fd fd
  0x4c0800000570: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x4c0800000580: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x4c0800000590: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
  0x4c08000005a0: fa fa 00 00 00 00 04 fa fa fa fa fa fa fa fa fa
  0x4c08000005b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==16072==ABORTING

Maybe this is also a root cause for sass/node-sass#2171

Taritsyn · 2019-10-30T07:36:33Z

@mgreter Thanks for fixes!

Taritsyn mentioned this issue Oct 29, 2019

Fixes for error #3019 #3020

Closed

saper added Bug - Confirmed Dev - PR Ready labels Oct 29, 2019

saper closed this as completed Oct 29, 2019

saper reopened this Oct 29, 2019

mgreter added Bug - Maybe and removed Bug - Confirmed labels Oct 29, 2019

mgreter added Bug - Confirmed and removed Bug - Maybe labels Oct 29, 2019

mgreter added the Dev - WIP label Oct 29, 2019

mgreter pushed a commit to mgreter/libsass that referenced this issue Oct 29, 2019

Extend error_src lifetime on c-api context

ed91ca4

Fixes sass#3019

mgreter mentioned this issue Oct 29, 2019

Extend error_src lifetime on c-api context #3022

Merged

mgreter closed this as completed in #3022 Oct 29, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sometimes the `sass_context_get_error_src` method returns an invalid pointer #3019

Sometimes the `sass_context_get_error_src` method returns an invalid pointer #3019

Taritsyn commented Oct 29, 2019

Taritsyn commented Oct 29, 2019

saper commented Oct 29, 2019

Taritsyn commented Oct 29, 2019

mgreter commented Oct 29, 2019 •

edited

Loading

Taritsyn commented Oct 29, 2019

mgreter commented Oct 29, 2019

saper commented Oct 29, 2019

mgreter commented Oct 29, 2019 •

edited

Loading

saper commented Oct 29, 2019

glebm commented Oct 29, 2019 •

edited

Loading

saper commented Oct 29, 2019

saper commented Oct 29, 2019

mgreter commented Oct 29, 2019

mgreter commented Oct 29, 2019 •

edited

Loading

glebm commented Oct 29, 2019 •

edited

Loading

mgreter commented Oct 29, 2019

glebm commented Oct 29, 2019

glebm commented Oct 29, 2019

mgreter commented Oct 29, 2019

glebm commented Oct 29, 2019 •

edited

Loading

mgreter commented Oct 29, 2019

mgreter commented Oct 29, 2019

Taritsyn commented Oct 29, 2019

saper commented Oct 30, 2019

saper commented Oct 30, 2019

saper commented Oct 30, 2019

Taritsyn commented Oct 30, 2019

Sometimes the sass_context_get_error_src method returns an invalid pointer #3019

Sometimes the sass_context_get_error_src method returns an invalid pointer #3019

Comments

Taritsyn commented Oct 29, 2019

Taritsyn commented Oct 29, 2019

saper commented Oct 29, 2019

Taritsyn commented Oct 29, 2019

mgreter commented Oct 29, 2019 • edited Loading

Taritsyn commented Oct 29, 2019

mgreter commented Oct 29, 2019

saper commented Oct 29, 2019

mgreter commented Oct 29, 2019 • edited Loading

saper commented Oct 29, 2019

glebm commented Oct 29, 2019 • edited Loading

saper commented Oct 29, 2019

saper commented Oct 29, 2019

mgreter commented Oct 29, 2019

mgreter commented Oct 29, 2019 • edited Loading

glebm commented Oct 29, 2019 • edited Loading

mgreter commented Oct 29, 2019

glebm commented Oct 29, 2019

glebm commented Oct 29, 2019

mgreter commented Oct 29, 2019

glebm commented Oct 29, 2019 • edited Loading

mgreter commented Oct 29, 2019

mgreter commented Oct 29, 2019

Taritsyn commented Oct 29, 2019

saper commented Oct 30, 2019

saper commented Oct 30, 2019

saper commented Oct 30, 2019

Taritsyn commented Oct 30, 2019

Sometimes the `sass_context_get_error_src` method returns an invalid pointer #3019

Sometimes the `sass_context_get_error_src` method returns an invalid pointer #3019

mgreter commented Oct 29, 2019 •

edited

Loading

mgreter commented Oct 29, 2019 •

edited

Loading

glebm commented Oct 29, 2019 •

edited

Loading

mgreter commented Oct 29, 2019 •

edited

Loading

glebm commented Oct 29, 2019 •

edited

Loading

glebm commented Oct 29, 2019 •

edited

Loading