Возможная утечка памяти на GeoIP_new API в C

Я пробовал следующий код на GeoIP 1.4.8 и 1.6.6, и он освобождает только 5 выделений из 40 распределений, сообщаемых valgrind.Возможная утечка памяти на GeoIP_new API в C

Я знаю «все еще достижимый» в соответствии с этим post, но я хочу убедиться, что это так. Мне кажется странным только освобождение 5 ассигнований. Есть идеи?

==1687== HEAP SUMMARY: 
==1687==  in use at exit: 35,128 bytes in 35 blocks 
==1687== total heap usage: 40 allocs, 5 frees, 36,847 bytes allocated 
==1687== 
==1687== 312 bytes in 1 blocks are still reachable in loss record 1 of 35 
==1687== at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==1687== by 0x4E3DA5E: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x40075E: main (in /home/pixie/a.out) 
==1687== 
==1687== 1,024 bytes in 1 blocks are still reachable in loss record 2 of 35 
==1687== at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==1687== by 0x4E3D9A5: _GeoIP_full_path_to (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x4E3DA70: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x40075E: main (in /home/pixie/a.out) 
==1687== 
==1687== 1,024 bytes in 1 blocks are still reachable in loss record 3 of 35 
==1687== at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==1687== by 0x4E3D9A5: _GeoIP_full_path_to (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x4E3DA83: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x40075E: main (in /home/pixie/a.out) 
==1687== 
==1687== 1,024 bytes in 1 blocks are still reachable in loss record 4 of 35 
==1687== at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==1687== by 0x4E3D9A5: _GeoIP_full_path_to (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x4E3DA96: _GeoIP_setup_dbfilename (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x4E3E789: GeoIP_new (in /usr/lib/libGeoIP.so.1.6.6) 
==1687== by 0x40075E: main (in /home/pixie/a.out) 
...

Код

#include <GeoIP.h> 

int main (int argc, char **argv) { 
    GeoIP * gp; 

    gp = GeoIP_new(GEOIP_STANDARD); 
    printf("%s\n", GeoIP_country_code_by_addr(gp, "216.58.216.238")); 
    GeoIP_delete(gp); 

    return 0; 
}

источник

2016-05-14 Pete Darrow

Вы должны быть осторожны с использованием библиотек, поскольку некоторые выделяют блоки памяти для использования самой библиотекой и не имеют особого значения для освобождения памяти, полагающейся на выход программы для ее обработки. Для более крупных, более хорошо известных библиотек публикуются списки исключений для 'valgrind' для учета такого типа распределения (например,« GTK + »и т. Д.). Я не знаю достаточно о geoip, чтобы сказать вам, если это то, что происходит, но, судя по вашему коду, это похоже на классические симптомы выделенной памяти, которые не находятся под вашим контролем. –

Спасибо, что указали это. Я начинаю думать, что это, вероятно, так. –

Если вы снова вызовете GeoIP_new и GeoIP_delete (так дважды в каждом), то это увеличится до 10 блоков? – immibis

Видимо следующий call делает работу (не задокументированных).

GeoIP_cleanup();

источник

2016-05-14 03:43:07

Возможная утечка памяти на GeoIP_new API в C

ответ

Смежные вопросы