由于
memory pools(g_slice),我的代码可能会丢失.我的问题是:我的代码中有什么可以避免泄漏的,或者这纯粹是一个GLib问题吗?
所有这些都被报道为“可能丢失”.
==2552==
==2552== 744 bytes in 3 blocks are possibly lost in loss record 6 of 8
==2552== at 0x40235BE: memalign (vg_replace_malloc.c:694)
==2552== by 0x402361B: posix_memalign (vg_replace_malloc.c:835)
==2552== by 0x408693E: ??? (in /usr/lib/libglib-2.0.so.0.1600.6)
==2552== by 0x4088112: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==2552== by 0x405B503: ??? (in /usr/lib/libglib-2.0.so.0.1600.6)
==2552== by 0x804876C: add_inv (in /home/user/a.out)
==2552== by 0x8048818: main (in /home/user/a.out)
#include <glib.h>
static GHashTable *hashtable1;
static GHashTable *hashtable2;
int add_inv (char *a, char *b) {
GHashTable *table = NULL;
gpointer old_value;
char *mykey = NULL;
int i, plus, *pointer;
for (i = 0; i < 2; i++)
{
if (i == 0)
{
table = hashtable1;
mykey = a;
}
else if (i == 1)
{
table = hashtable2;
mykey = b;
}
old_value = g_hash_table_lookup (table, mykey);
if (old_value != NULL)
{
pointer = (int *) old_value;
plus = *pointer + 10;
}
else
plus = 10;
pointer = g_malloc (sizeof (int));
*pointer = plus;
g_hash_table_replace (table, g_strdup (mykey), pointer);
}
}
int main () {
int i;
hashtable1 = g_hash_table_new_full (g_str_hash, g_str_equal, (GDestroyNotify) g_free, g_free);
hashtable2 = g_hash_table_new_full (g_str_hash, g_str_equal, (GDestroyNotify) g_free, g_free);
for (i = 0; i < 20; i++)
{
char *a = g_strdup ("val1");
char *b = g_strdup ("val2");
add_inv (a, b);
g_free (a);
g_free (b);
}
g_hash_table_destroy (hashtable1);
g_hash_table_destroy (hashtable2);
return 0;
}
最佳答案 设置G_SLICE环境变量以重新配置GSlice内存分配器.
G_SLICE=always-malloc ./your_application
这是GLib documentation的相关部分.
This will cause all slices allocated through g_slice_alloc() and
released by g_slice_free1() to be actually allocated via direct calls
to g_malloc() and g_free(). This is most useful for memory checkers
and similar programs that use Bohem GC alike algorithms to produce
more accurate results. It can also be in conjunction with debugging
features of the system’s malloc implementation such as glibc’s
MALLOC_CHECK_=2 to debug erroneous slice allocation code, allthough
debug-blocks usually is a better suited debugging tool.