ASAN не сообщает об утечке памяти для функций glib, связанных с GPtrArray - PullRequest
1 голос
/ 23 декабря 2019

Я обнаружил, что ASAN не сообщает об утечке памяти для функций glib * GPtrArray. Например:

$ cat test_asan.c
#include <glib.h>
int main()
{
    GPtrArray *gparray = g_ptr_array_new_with_free_func(g_free);

    g_ptr_array_add(gparray, g_strdup("--"));
}

Создайте и запустите этот файл:

$ clang -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fsanitize=address -g test_asan.c -o test_asan -lglib-2.0
$ ./test_asan
$

Ничего не сообщается. Но на самом деле вышеупомянутая программа забыла вызвать g_ptr_array_free (gparray, TRUE); в конце функции main.

Кто-нибудь может дать какое-то объяснение этому поведению? Или я что-то пропустил?

1 Ответ

0 голосов
/ 26 декабря 2019

LeakSanitizer использует простой алгоритм , который сканирует кадры стека, регистры, глобальные и локальные переменные потока и достижимые выделения кучи для данных, которые выглядят как адреса памяти. Это происходит без обратной связи с компилятором, поэтому несвязанные, случайные или устаревшие данные могут привести к тому, что потерянная память будет считаться достижимой. Таким образом, алгоритм является неточным и, как известно, генерирует ложные отрицания (см., Например, здесь или здесь ), которые на практике зависят от версии компилятора / библиотеки и / или флагов.

Обычно такие проблемы, как описанные вами, возникают, когда устаревшее содержимое кадра main (gparray в вашем случае) оказывается не перезаписанным при запуске сканирования LSan.

Как этопроблема дизайна, с этим мало что можно поделать.

...