Avoid GLib and Valgrind memory pools, possibly lost in C

Thanks to the memory pools (g_slice) , I get possibly lost in my code. My question is: is there anything I could do in my code to avoid leakage or is it just a GLib problem?

All are reported as "possibly lost."

 ==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; } 
+4
source share
1 answer

Set the G_SLICE environment variable to reconfigure the GSlice memory allocator.

 G_SLICE=always-malloc ./your_application 

Here is the related part of the GLib documentation .

This will cause all slices to be allocated through g_slice_alloc () and released by g_slice_free1 () for actual distribution via direct calls to g_malloc () and g_free (). It is most useful for memory checks and similar programs that use Bohem GC algorithms to produce more accurate results. It can also be associated with debugging features of the implementation of the malloc system, such as glibc's MALLOC_CHECK_ = 2 for debugging the error code for fragment selection, allthough debug-blocks are usually better for debugging.

+2
source

Source: https://habr.com/ru/post/1412111/


All Articles