Libsass: Dépassement de la mémoire tampon MSVC x86_64 dans le rapport d'erreurs (régression entre 3.3.5 et 3.3.6)

Créé le 24 avr. 2016  ·  14Commentaires  ·  Source: sass/libsass

Cela vient à l'origine de https://github.com/dahlia/libsass-python/pull/149

J'ai du mal à comprendre exactement _pourquoi_ cela arrive, mais je posterai ce que j'ai jusqu'à présent :)

Ce commit semble causer le problème que je vois : https://github.com/sass/libsass/commit/527f3a8 (#2025)
L'extraction de la révision précédente (f8cad4e) semble réussir.

Mon petit harnais d'essai

Vous pouvez voir le code ici si c'est plus facile : 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

Sortie à 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

Sortie à 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

L'attachement du débogueur en cas d'échec donne le message suivant :

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

Et dépose un point d'arrêt sur : https://github.com/sass/libsass/blob/527f3a8/src/sass_context.cpp#L143

Bug - Confirmed Dev - PR Ready

Tous les 14 commentaires

Premièrement :clap: pour ce rapport de bogue, à peu près sur place comme nous le voulons. Si vous prenez le temps de remplacer D:\Programs par ProgramFiles(x86) et d'installer visual studio dans un chemin standard ( Microsoft Visual Studio 12.0 AFAIK) la prochaine fois, je le nommerai officiellement pour le rapport de bogue de l'année :sourire:

Il se fait déjà tard ici, mais je vais jeter un coup d'œil rapide ...

Il semble que la suppression de /GL (optimisation du programme) fasse disparaître le problème ...
Pour clarifier, je reçois une erreur de segmentation lorsque l'optimisation est activée .. ok, vous voyez que vous avez la même chose.
Puisque vous dites qu'il est venu avec le nouvel essai ajouté, je soupçonne des problèmes de déroulement de la pile.
Ceci est souvent lié aux options du compilateur, mais il est trop tôt pour dire quoi que ce soit de précis.

Fera et rapportera. Je n'ai plus d'espace sur mon SSD, je vais donc probablement devoir faire tourner une VM

Changer en /GR fait l'affaire ! -- Je pense que je peux corriger cela dans les drapeaux que je passe à setuptools (python).

Merci pour le conseil!

Hmmm... c'est un peu difficile à faire car ce sont des valeurs par défaut difficiles à remplacer -- avez-vous une idée de la raison pour laquelle ce commit casse /GL ?

Oui, parce que la mémoire est probablement plus brouillée, il est donc probablement aussi plus facile d'obtenir des erreurs de segmentation via des pointeurs suspendus ou des dépassements de mémoire tampon, etc. première fois. Le correctif est en cours, écrira un peu plus dans le PR.

<3 tu es le meilleur

Si vous aimez y réfléchir vous-même, voici la ligne incriminée :

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

Voir https://github.com/sass/libsass/pull/2048 pour le correctif proposé. Merci pour le rapport !

Je me souviens de quelque chose de similaire dans un code que j'ai écrit il y a longtemps - je pensais que la norme protégeait contre la collecte temporaire de la chaîne, mais peut-être pas.

Ce patch semble faire réussir le code :

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;

Oh doux, nous sommes arrivés à la même conclusion :D

Oui, j'ai déjà vu celui-là avec la gestion de la mémoire, où le destructeur était appelé dans un ordre étrange qui conduisait essentiellement au même problème (même compilateur).

Ah, maintenant je me souviens, c'est exactement la raison (AFAIR) pour laquelle nous avons la macro SASS_MEMORY_NEW pour l'allocation de nouveaux objets. C'était ce PR : https://github.com/sass/libsass/pull/1462 ... pas sûr à 100%, mais mon instinct dit qu'ils ont tous les deux la même racine commune.

Belle prise à tous
Le 25 avril 2016 à 09h29, "Marcel Greter" [email protected] a écrit :

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

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/sass/libsass/issues/2046#event-639249983

Cette page vous a été utile?
0 / 5 - 0 notes