Libsass: Saturação de buffer MSVC x86_64 no relatório de erros (regressão entre 3.3.5 e 3.3.6)

Criado em 24 abr. 2016  ·  14Comentários  ·  Fonte: sass/libsass

Isso vem originalmente de https://github.com/dahlia/libsass-python/pull/149

Estou tendo dificuldade em entender exatamente _por que isso acontece, mas vou postar o que tenho até agora :)

Este commit parece causar o problema que estou vendo: https://github.com/sass/libsass/commit/527f3a8 (# 2025)
Verificar a revisão anterior (f8cad4e) parece ter sucesso.

Meu pequeno equipamento de teste

Você pode visualizar o código aqui se for mais fácil: https://github.com/asottile/libsass/commit/f40ae24025234b73ca86adece62dec0e35884eb1

main.cpp

#include <sass/context.h>
#include <iostream>

int main() {
    std::cout << "Making data context" << std::endl;
    struct Sass_Data_Context* context = sass_make_data_context(sass_copy_c_string(""));
    std::cout << "Compiling data context" << std::endl;
    sass_compile_data_context(context);
    std::cout << "Getting output context" << std::endl;
    struct Sass_Context* ctx = sass_data_context_get_context(context);
    std::cout << "Printing error status" << std::endl;
    std::cout << sass_context_get_error_status(ctx) << std::endl;
    std::cout << "Printing error message" << std::endl;
    std::cout << sass_context_get_error_message(ctx) << std::endl;
    sass_delete_data_context(context);

    return 0;
}

test.bat

"D:\Programs\VS2015\VC\BIN\amd64\cl.exe" ^
    /I.\include -ID:\Programs\VS2015\VC\INCLUDE ^
    /c /nologo /W3 /WX- /GL /DNDEBUG -O2 /Oi /Zi /EHsc /MT ^
    src/*.c
"D:\Programs\VS2015\VC\BIN\amd64\cl.exe" ^
    /I.\include ^
    "-ID:\Programs\VS2015\VC\INCLUDE" ^
    "-ID:\Programs\VS2015\VC\ATLMFC\INCLUDE" ^
    "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt" ^
    "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um" ^
    "-IC:\Program Files (x86)\Windows Kits\8.1\include\\shared" ^
    "-IC:\Program Files (x86)\Windows Kits\8.1\include\\um" ^
    "-IC:\Program Files (x86)\Windows Kits\8.1\include\\winrt" ^
    /c /nologo /W3 /WX- /GL /DNDEBUG -O2 /Oi /Zi /EHsc /MT ^
    ./main.cpp src/*.cpp 
"D:\Programs\VS2015\VC\BIN\amd64\link.exe" ^
    "-LIBPATH:D:\Programs\VS2015\VC\LIB\amd64" ^
    "-LIBPATH:D:\Programs\VS2015\VC\ATLMFC\LIB\amd64" ^
    "-LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64" ^
    "-LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64" ^
    "-LIBPATH:C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64" ^
    "-INCREMENTAL:NO" "-OUT:main.exe" "-Debug" "-nologo" "-LTCG" ^
    *.obj
main.exe

Saída em f8cad4e

C:\Users\Anthony\Desktop\git\libsass-python\libsass>"D:\Programs\VS2015\VC\BIN\amd64\cl.exe"     /I.\include -ID:\Programs\VS2015\VC\INCLUDE     /c /nologo /W3 /WX- /GL /DNDEBUG -O2 /Oi /Zi /EHsc /MT     src/*.c
c99func.c
cencode.c

C:\Users\Anthony\Desktop\git\libsass-python\libsass>"D:\Programs\VS2015\VC\BIN\amd64\cl.exe"     /I.\include     "-ID:\Programs\VS2015\VC\INCLUDE"     "-ID:\Programs\VS2015\VC\ATLMFC\INCLUDE"     "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt"     "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um"     "-IC:\Program Files (x86)\Windows Kits\8.1\include\\shared"     "-IC:\Program Files (x86)\Windows Kits\8.1\include\\um"     "-IC:\Program Files (x86)\Windows Kits\8.1\include\\winrt"     /c /nologo /W3 /WX- /GL /DNDEBUG -O2 /Oi /Zi /EHsc /MT     ./main.cpp src/*.cpp
main.cpp
ast.cpp
base64vlq.cpp
bind.cpp
src/bind.cpp(175): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
color_maps.cpp
constants.cpp
context.cpp
cssize.cpp
emitter.cpp
environment.cpp
error_handling.cpp
eval.cpp
expand.cpp
extend.cpp
file.cpp
functions.cpp
inspect.cpp
json.cpp
lexer.cpp
listize.cpp
Compiling...
memory_manager.cpp
node.cpp
output.cpp
parser.cpp
plugins.cpp
position.cpp
prelexer.cpp
remove_placeholders.cpp
sass.cpp
sass2scss.cpp
sass_context.cpp
sass_functions.cpp
sass_util.cpp
sass_values.cpp
source_map.cpp
to_c.cpp
to_value.cpp
units.cpp
utf8_string.cpp
util.cpp
Compiling...
values.cpp

C:\Users\Anthony\Desktop\git\libsass-python\libsass>"D:\Programs\VS2015\VC\BIN\amd64\link.exe"     "-LIBPATH:D:\Programs\VS2015\VC\LIB\amd64"     "-LIBPATH:D:\Programs\VS2015\VC\ATLMFC\LIB\amd64"     "-LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64"     "-LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64"     "-LIBPATH:C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64"     "-INCREMENTAL:NO" "-OUT:main.exe" "-Debug" "-nologo" "-LTCG"     *.obj
Generating code
Finished generating code

C:\Users\Anthony\Desktop\git\libsass-python\libsass>main.exe
Making data context
Compiling data context
Getting output context
Printing error status
3
Printing error message
Internal Error: Data context created with empty source string

Saída em 527f3a8

C:\Users\Anthony\Desktop\git\libsass-python\libsass>"D:\Programs\VS2015\VC\BIN\amd64\cl.exe"     /I.\include -ID:\Programs\VS2015\VC\INCLUDE     /c /nologo /W3 /WX- /GL /DNDEBUG -O2 /Oi /Zi /EHsc /MT     src/*.c
c99func.c
cencode.c

C:\Users\Anthony\Desktop\git\libsass-python\libsass>"D:\Programs\VS2015\VC\BIN\amd64\cl.exe"     /I.\include     "-ID:\Programs\VS2015\VC\INCLUDE"     "-ID:\Programs\VS2015\VC\ATLMFC\INCLUDE"     "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt"     "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um"     "-IC:\Program Files (x86)\Windows Kits\8.1\include\\shared"     "-IC:\Program Files (x86)\Windows Kits\8.1\include\\um"     "-IC:\Program Files (x86)\Windows Kits\8.1\include\\winrt"     /c /nologo /W3 /WX- /GL /DNDEBUG -O2 /Oi /Zi /EHsc /MT     ./main.cpp src/*.cpp
main.cpp
ast.cpp
base64vlq.cpp
bind.cpp
src/bind.cpp(175): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
color_maps.cpp
constants.cpp
context.cpp
cssize.cpp
emitter.cpp
environment.cpp
error_handling.cpp
eval.cpp
expand.cpp
extend.cpp
file.cpp
functions.cpp
inspect.cpp
json.cpp
lexer.cpp
listize.cpp
Compiling...
memory_manager.cpp
node.cpp
output.cpp
parser.cpp
plugins.cpp
position.cpp
prelexer.cpp
remove_placeholders.cpp
sass.cpp
sass2scss.cpp
sass_context.cpp
sass_functions.cpp
sass_util.cpp
sass_values.cpp
source_map.cpp
to_c.cpp
to_value.cpp
units.cpp
utf8_string.cpp
util.cpp
Compiling...
values.cpp

C:\Users\Anthony\Desktop\git\libsass-python\libsass>"D:\Programs\VS2015\VC\BIN\amd64\link.exe"     "-LIBPATH:D:\Programs\VS2015\VC\LIB\amd64"     "-LIBPATH:D:\Programs\VS2015\VC\ATLMFC\LIB\amd64"     "-LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64"     "-LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64"     "-LIBPATH:C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64"     "-INCREMENTAL:NO" "-OUT:main.exe" "-Debug" "-nologo" "-LTCG"     *.obj
Generating code
Finished generating code

C:\Users\Anthony\Desktop\git\libsass-python\libsass>main.exe
Making data context

Anexar o depurador em caso de falha fornece a seguinte mensagem:

Unhandled exception at 0x00007FF77A8F8814 in main.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.

E descarta um ponto de interrupção em: https://github.com/sass/libsass/blob/527f3a8/src/sass_context.cpp#L143

Bug - Confirmed Dev - PR Ready

Todos 14 comentários

Primeiro: aplausos: para aquele relatório de bug, quase no local como queremos. Se você reservar um tempo para substituir D:\Programs por ProgramFiles(x86) e instalar o Visual Studio em um caminho padrão ( Microsoft Visual Studio 12.0 AFAIK) da próxima vez, irei indicá-lo oficialmente para o relatório de bug de o ano: sorrindo:

Já está ficando tarde aqui, mas vou dar uma espiada rápida ...

Parece que remover /GL (otimização do programa) faz com que o problema desapareça ...
Para esclarecer, estou recebendo segfault quando a otimização está habilitada .. ok, veja você tem o mesmo.
Já que você disse que veio com o try recém-adicionado, suspeito de problemas de desenrolamento de pilha.
Isso geralmente está relacionado às opções do compilador, mas é muito cedo para dizer algo definitivo.

Vou fazer e relatar de volta. Estou sem espaço no meu SSD, então provavelmente vou precisar ativar uma VM

Mudar para /GR resolve! - Acho que posso consertar isso nas sinalizações que passo para o setuptools (python).

Obrigado pela dica!

Hmmm ... isso é um pouco difícil de fazer, pois esses são alguns padrões que são difíceis de substituir - alguma ideia de por que esse commit quebra /GL ?

Sim, porque a memória é provavelmente mais embaralhada, então provavelmente também é mais fácil obter segfaults por meio de ponteiros pendentes ou saturações de buffer, etc. Mas já posso relatar que é um "problema" temido e difícil de detectar que, na verdade, não estamos enfrentando primeira vez. O conserto está em andamento, vou escrever um pouco mais no PR.

<3 você é o melhor

Se você gosta de pensar nisso, esta é a linha ofensiva:

sass_copy_c_string(msg_stream.str().c_str())

Consulte https://github.com/sass/libsass/pull/2048 para a correção proposta. Obrigado pelo relatório!

Eu me lembro de algo semelhante a isso em algum código que escrevi há muito tempo - pensei que o padrão protegia contra a coleta temporária de strings, mas talvez não.

Este patch parece fazer o código ter sucesso:

diff --git a/src/sass_context.cpp b/src/sass_context.cpp
index e3f34af..9105866 100644
--- a/src/sass_context.cpp
+++ b/src/sass_context.cpp
@@ -140,7 +140,8 @@ extern "C" {
       json_append_member(json_err, "message", json_mkstring(e.what()));
       json_append_member(json_err, "formatted", json_mkstring(msg_stream.str().c_str()));
       try { c_ctx->error_json = json_stringify(json_err, "  "); } catch(...) {}
-      c_ctx->error_message = sass_copy_c_string(msg_stream.str().c_str());
+      std::string s = msg_stream.str();
+      c_ctx->error_message = sass_copy_c_string(s.c_str());
       c_ctx->error_text = sass_copy_c_string(e.what());
       c_ctx->error_status = 3;
       c_ctx->output_string = 0;

Nossa, chegamos à mesma conclusão: D

Sim, vi isso antes com o gerenciamento de memória, onde o destruidor era chamado em uma ordem estranha que levava basicamente ao mesmo problema (mesmo compilador).

Ah, agora me lembro, esse é exatamente o motivo (AFAIR) pelo qual temos a macro SASS_MEMORY_NEW para alocação de novos objetos. Esse foi este PR: https://github.com/sass/libsass/pull/1462 ... não 100% certo, mas meu instinto diz que eles têm a mesma raiz comum.

Bom pegar vocês todos
Em 25 de abril de 2016, às 9h29, "Marcel Greter" [email protected] escreveu:

Fechado # 2046 https://github.com/sass/libsass/issues/2046 via # 2048
https://github.com/sass/libsass/pull/2048.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/sass/libsass/issues/2046#event -639249983

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

Nimce picture Nimce  ·  4Comentários

nex3 picture nex3  ·  9Comentários

delijah picture delijah  ·  7Comentários

bdkjones picture bdkjones  ·  6Comentários

JohnMica picture JohnMica  ·  3Comentários