Question

当我使用语言c进行编码时，在使用 valgrind 检查我的c程序的内存后，我一直收到仍然可以警告但是我从来没有能够找到它们。我已经阅读了几篇关于此的文章，有人说这不是问题，有人说我们以后重用相同的代码会有问题。所以我决定让这些仍然可以到达的memrories 消失。
所以以下是我的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;
}

当我在ubuntu上使用它在终端上运行它时：

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

Answer 1

引用的内存位置由您正在调用的glib函数生成。

您已经拨打g_free了，所以您可能无法做到这一点。

哪里是我仍然可以访问的内存（在valgrind内存检查c程序后）？

1 个答案: