LINUX.ORG.RU
Форум — Development  

c, glib, memory leak?


0

0

Код:
#include <glib.h>

int main()
{

typedef struct
{
gint variable;
} __attribute__((__packed__)) test;

//for(i=0; i<100; i++)
{
test* array = g_slice_new(test);
g_slice_free(test, array);
}
}


$ gcc main.c `pkg-config --libs --cflags glib-2.0` -ggdb
$ valgrind ./a.out

==2975== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==2975== malloc/free: in use at exit: 4,044 bytes in 8 blocks.
==2975== malloc/free: 8 allocs, 0 frees, 4,044 bytes allocated.
==2975== For counts of detected errors, rerun with: -v
==2975== searching for pointers to 8 not-freed blocks.
==2975== checked 72,016 bytes.
==2975==
==2975== LEAK SUMMARY:
==2975== definitely lost: 0 bytes in 0 blocks.
==2975== possibly lost: 0 bytes in 0 blocks.
==2975== still reachable: 4,044 bytes in 8 blocks.
==2975== suppressed: 0 bytes in 0 blocks.

Откуда появились 4Kb выделенных и потерянных? От glib? Его инициализации?

anonymous
← [вещества] make и симлинки
перенаправление команды → 

GString* s = g_string_sized_new(1);
g_string_free(s, TRUE);

Так же увеличивает это кол-во, правда только на 150 с копейками байт...

anonymous
()

ну так попроси валгринд сказать, где именно была совершена диверсия и посмотри сам.

anonymous
()

Ну закэшировала глиб выделенные куски памяти, чтоб потом с маллоком не возиться, если ты снова g_slice_new звать будешь. Что страшного-то?

anonymous
()
Ответ на: комментарий от anonymous

==3832== 120 bytes in 1 blocks are still reachable in loss record 1 of 6 ==3832== at 0x4021C8A: memalign (vg_replace_malloc.c:460) ==3832== by 0x4021D3E: posix_memalign (vg_replace_malloc.c:569) ==3832== by 0x409291E: (within /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x40940C1: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x80484F0: main (1.c:11) ==3832== ==3832== ==3832== 360 bytes in 3 blocks are still reachable in loss record 2 of 6 ==3832== at 0x4021C8A: memalign (vg_replace_malloc.c:460) ==3832== by 0x4021D3E: posix_memalign (vg_replace_malloc.c:569) ==3832== by 0x409291E: (within /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x40940F2: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x80484F0: main (1.c:11) ==3832== ==3832== ==3832== 508 bytes in 1 blocks are still reachable in loss record 3 of 6 ==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397) ==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x409222C: (within /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x4093F34: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x80484F0: main (1.c:11) ==3832== ==3832== ==3832== 508 bytes in 1 blocks are still reachable in loss record 4 of 6 ==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397) ==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x40921E7: (within /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x4093F34: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x80484F0: main (1.c:11) ==3832== ==3832== ==3832== 508 bytes in 1 blocks are still reachable in loss record 5 of 6 ==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397) ==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x40921CA: (within /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x4093F34: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x80484F0: main (1.c:11) ==3832== ==3832== ==3832== 2,040 bytes in 1 blocks are still reachable in loss record 6 of 6 ==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397) ==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x4093EED: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6) ==3832== by 0x80484F0: main (1.c:11) ==3832== ==3832== LEAK SUMMARY: ==3832== definitely lost: 0 bytes in 0 blocks. ==3832== possibly lost: 0 bytes in 0 blocks. ==3832== still reachable: 4,044 bytes in 8 blocks. ==3832== suppressed: 0 bytes in 0 blocks.

А в fini часть не вариант освобождение запихнуть???

anonymous
()
Ответ на: комментарий от anonymous

sorry,
==3832== 120 bytes in 1 blocks are still reachable in loss record 1 of 6
==3832== at 0x4021C8A: memalign (vg_replace_malloc.c:460)
==3832== by 0x4021D3E: posix_memalign (vg_replace_malloc.c:569)
==3832== by 0x409291E: (within /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x40940C1: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x80484F0: main (1.c:11)
==3832==
==3832==
==3832== 360 bytes in 3 blocks are still reachable in loss record 2 of 6
==3832== at 0x4021C8A: memalign (vg_replace_malloc.c:460)
==3832== by 0x4021D3E: posix_memalign (vg_replace_malloc.c:569)
==3832== by 0x409291E: (within /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x40940F2: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x80484F0: main (1.c:11)
==3832==
==3832==
==3832== 508 bytes in 1 blocks are still reachable in loss record 3 of 6
==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397)
==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x409222C: (within /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x4093F34: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x80484F0: main (1.c:11)
==3832==
==3832==
==3832== 508 bytes in 1 blocks are still reachable in loss record 4 of 6
==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397)
==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x40921E7: (within /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x4093F34: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x80484F0: main (1.c:11)
==3832==
==3832==
==3832== 508 bytes in 1 blocks are still reachable in loss record 5 of 6
==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397)
==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x40921CA: (within /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x4093F34: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x80484F0: main (1.c:11)
==3832==
==3832==
==3832== 2,040 bytes in 1 blocks are still reachable in loss record 6 of 6
==3832== at 0x4021E22: calloc (vg_replace_malloc.c:397)
==3832== by 0x407D50B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x4093EED: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==3832== by 0x80484F0: main (1.c:11)
==3832==
==3832== LEAK SUMMARY:
==3832== definitely lost: 0 bytes in 0 blocks.
==3832== possibly lost: 0 bytes in 0 blocks.
==3832== still reachable: 4,044 bytes in 8 blocks.
==3832== suppressed: 0 bytes in 0 blocks.

anonymous
()

>Откуда появились 4Kb выделенных и потерянных? От glib? Его инициализации?

Про выделенные, это правда. Но при этом никто ничего не терял! Стоит же ведь:
==2975== LEAK SUMMARY:
==2975== definitely lost: 0 bytes in 0 blocks.
==2975== possibly lost: 0 bytes in 0 blocks.
==2975== still reachable: 4,044 bytes in 8 blocks.

Т.е. 4 Кб освобождены, но указатели на них не обнулены. Т.е. 4 Кб dangled.

Ну, а то что там 8 alloc и 0 free - выходит как-то по-другому, чем
через free, была освобождена память - т.е. такой способ был
категоризирован под ERROR SUMMARY. Интересно...

Андрей

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← [вещества] make и симлинки
Development
перенаправление команды →