c - 我仍然可以访问的内存在哪里(在对 C 程序进行 valgrind 内存检查之后)？

Question

当我这些天用c语言编码时，在使用valgrind检查我的c程序的内存后，我不断收到仍然可达警告但我从来没有能够找到它们。我读过几篇关于此的文章，有人说这不是问题，有人说我们以后重用相同的代码时可能会遇到问题。所以我决定让这些仍可触及的内存消失。
所以下面是我的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，因此您可能对此无能为力。