Я разрабатываю библиотеку, используя ряд glib-данных (GHashTable, GSList и т.д.). Я часто проверяю свой код на утечки памяти, используя valgrind. Большинство вопросов, о которых указывает valgrind, довольно легко исправить, однако есть несколько, которые я не могу понять.
Все они сообщаются как "возможно потерянные".
В верхней части valtind stacktrace я всегда нахожу те же 4 библиотеки:
==29997== 1,512 bytes in 3 blocks are possibly lost in loss record 24 of 25
==29997== at 0x4004B11: memalign (vg_replace_malloc.c:532)
==29997== by 0x4004B6B: posix_memalign (vg_replace_malloc.c:660)
==29997== by 0x5E9AC4: ??? (in /lib/libglib-2.0.so.0.1200.3)
==29997== by 0x5EA4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)
Далее в стеке вызовов всегда есть вызов функции glib, такой как g_key_file_new(), g_slist_prepend(), g_strsplit(), g_key_file_load_from_file(), g_file_get_contents().
Мои вопросы:
-
Кто-нибудь сталкивался с этим и нашел способ обойти его?
-
Или это то, что я могу игнорировать? Это связано с glib с использованием пулов памяти, как предложено здесь?
Я использую
- valgrind-3.5.0
- glib-2.12.3
- gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
- Версия CentOS 5.5 (Final)