Необнаруженная утечка с помощью asan и strsep () - PullRequest
Новая
       28

Необнаруженная утечка с помощью asan и strsep ()

0 голосов
/ 21 января 2019

GCC 8.2.0 не обнаруживает утечку в следующем коде, скомпилированном с -fsanitize=address: 

#include <string.h>
#include <stdlib.h>
#include <stdio.h>

int main()
{
        char *str1 = "tok1:val2";
        char *str1_dup = strndup(str1, strlen(str1));
        char *str1_dup_head = str1_dup;

        char *tok1 = strsep(&str1_dup, ":");

        // What should be done to avoid the memory leak
        //free(str1_dup_head);
        return 0;
}

Однако утечка обнаруживается, когда:

  • скомпилировано с-fsanitize=leak
  • скомпилировано с clang -fsanitize=address
  • , когда копия заголовка указателя strsep() (str1_dup_cpy) не сохраняется (см. Код ниже) 
#include <string.h>
#include <stdlib.h>
#include <stdio.h>

int main()
{
        char *str1 = "tok1:val2";
        char *str1_dup = strndup(str1, strlen(str1));
        //char *str1_dup_head = str1_dup;

        char *tok1 = strsep(&str1_dup, ":");

        // What should be done to avoid the memory leak
        //free(str1_dup_head);
        return 0;
}

Есть идеи, почему такое поведение?Должно ли оно быть обнаружено -fsanitize=address?

1 Ответ

0 голосов
/ 21 января 2019

LeakSanitizer по своему дизайну использует очень примитивный алгоритм для обнаружения утечек.Всякий раз, когда ссылка на выделенный блок оказывается где-то в стеке, регистре или блоке динамической кучи, LSan считает его «достижимым» и, таким образом, не сообщает об утечке.Это делает его очень чувствительным к версиям компилятора, опциям оптимизации (т. Е. Независимо от того, выкладывается ли переменная в стек или нет) и т. Д. Я сильно подозреваю, что вы испытываете это ограничение.

...