-1
Когда я кодирование на языке C эти дней, я продолжаю получать все еще достижимые предупреждения после использования Valgrind для проверки памяти моей программы гр , но я никогда не смог найти их. Я прочитал несколько статей об этом, и кто-то сказал, что это не проблема, некоторые говорят, что у нас могут быть проблемы при повторном использовании того же кода позже. Поэтому я решил сделать эти еще доступными мемуарами исчезнуть.
Итак, мой код c. Я действительно хочу знать, где мои неподвижные воспоминания? И как я мог бы очистить их до?где моя неподвижная память (после проверки памяти valgrind для программ c)?
#include <stdio.h>
#include <stdint.h>
#include <glib.h>
#include <stdlib.h>
#include <string.h>
typedef struct _ddict_application_t{
char *name;
uint32_t code;
struct _ddict_application_t *next;
} ddict_application_t;
ddict_application_t *parse_applications(void) {
char *table[10] = {
"the_first",
"the_seoncd",
"the_third",
"the_fourth",
"the_fifth",
"the_sixth",
"the_seventh",
"the_eighth",
"the_ninth",
"the_tenth"
};
ddict_application_t *head = NULL;
ddict_application_t *current = NULL;
for(int i = 0; i < 10; i++) {
if(i==0) {
head = g_new(ddict_application_t, 1);
head->name = NULL;
head->code = 0;
head->next = NULL;
head->name = strdup((const char*)table[i]);
head->code = i*37+21;
head->next = current = g_new(ddict_application_t, 1);
current->name = NULL;
current->code = 0;
current->next = NULL;
continue;
}
current->name = strdup((const char*)(table[i]));
current->code = i*37+21;
if(i+1 == 10)
current = current->next = NULL;
else
current = current->next = g_new(ddict_application_t, 1);
}
return head;
}
void ddict_free(ddict_application_t *appl) {
ddict_application_t *a = NULL;
ddict_application_t *an = NULL;
for(a = appl; a; a = an) {
an = a->next;
g_free(a->name);
g_free(a);
}
}
void print_applications(ddict_application_t *appl) {
if(!appl) {
fprintf(stderr, "application passed is NULL\n");
exit(1);
}
ddict_application_t *tmp = appl;
while(tmp) {
fprintf(stdout, "Application: %s [%u]\n", tmp->name, tmp->code);
tmp = tmp->next;
}
}
int main(int argc, char *argv[]) {
ddict_application_t *appl = parse_applications();
print_applications(appl);
ddict_free(appl);
return 1;
}
И когда я запускаю его на терминале с этим на убунту:
gcc linked_list.c -o test -std=gnu99 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -lglib-2.0 -g
И скомпилировать его с Valgrind:
valgrind --show-leak-kinds=all --leak-check=full -v ./test
Тогда Valgrind дал мне следующий результат:
Application: the_first [21]
Application: the_seoncd [58]
Application: the_third [95]
Application: the_fourth [132]
Application: the_fifth [169]
Application: the_sixth [206]
Application: the_seventh [243]
Application: the_eighth [280]
Application: the_ninth [317]
Application: the_tenth [354]
==2370==
==2370== HEAP SUMMARY:
==2370== in use at exit: 18,604 bytes in 6 blocks
==2370== total heap usage: 28 allocs, 22 frees, 19,977 bytes allocated
==2370==
==2370== Searching for pointers to 6 not-freed blocks
==2370== Checked 109,328 bytes
==2370==
==2370== 4 bytes in 1 blocks are still reachable in loss record 1 of 6
==2370== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2370== by 0x4EC8102: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4EC8644: g_private_get (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4EA088C: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E726CD: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E9383A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==2370== by 0x40105FA: call_init (dl-init.c:30)
==2370== by 0x40105FA: _dl_init (dl-init.c:120)
==2370== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==2370==
==2370== 32 bytes in 1 blocks are still reachable in loss record 2 of 6
==2370== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2370== by 0x4E89700: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E72734: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E9383A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==2370== by 0x40105FA: call_init (dl-init.c:30)
==2370== by 0x40105FA: _dl_init (dl-init.c:120)
==2370== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==2370==
==2370== 64 bytes in 1 blocks are still reachable in loss record 3 of 6
==2370== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2370== by 0x4E89700: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E7271F: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E9383A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==2370== by 0x40105FA: call_init (dl-init.c:30)
==2370== by 0x40105FA: _dl_init (dl-init.c:120)
==2370== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==2370==
==2370== 88 bytes in 1 blocks are still reachable in loss record 4 of 6
==2370== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2370== by 0x4E896A8: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4EA08B2: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E726CD: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E9383A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==2370== by 0x40105FA: call_init (dl-init.c:30)
==2370== by 0x40105FA: _dl_init (dl-init.c:120)
==2370== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==2370==
==2370== 2,032 bytes in 1 blocks are still reachable in loss record 5 of 6
==2370== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2370== by 0x4E89700: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4EA0B1B: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E726CD: g_hash_table_new_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E9383A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==2370== by 0x40105FA: call_init (dl-init.c:30)
==2370== by 0x40105FA: _dl_init (dl-init.c:120)
==2370== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==2370==
==2370== 16,384 bytes in 1 blocks are still reachable in loss record 6 of 6
==2370== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2370== by 0x4E896A8: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x4E9384B: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
==2370== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==2370== by 0x40105FA: call_init (dl-init.c:30)
==2370== by 0x40105FA: _dl_init (dl-init.c:120)
==2370== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==2370==
==2370== LEAK SUMMARY:
==2370== definitely lost: 0 bytes in 0 blocks
==2370== indirectly lost: 0 bytes in 0 blocks
==2370== possibly lost: 0 bytes in 0 blocks
==2370== still reachable: 18,604 bytes in 6 blocks
==2370== suppressed: 0 bytes in 0 blocks
@BeyelerStudios Я пробовал, но у меня такой же результат, как и раньше. – SWIIWII
@BeyelerStudios совсем нет. – SWIIWII
Не уверен, что это может быть проблемой, но чтобы быть последовательным, вы должны использовать 'g_strdup'. –