Valgrind informa que la memoria 'posiblemente se ha perdido' cuando se usan tipos de datos glib

Estoy desarrollando una biblioteca utilizando varias estructuras de datos glib (GHashTable, GSList, etc.). He estado revisando mi código con frecuencia para detectar fugas de memoria usando valgrind. La mayoría de los problemas que Valgrind señala son bastante fáciles de solucionar, sin embargo, hay algunos que no puedo descifrar.Valgrind informa que la memoria 'posiblemente se ha perdido' cuando se usan tipos de datos glib

Todos estos se informan como "posiblemente perdidos".

En la parte superior de la StackTrace valgrind, siempre encuentro los mismos 4 bibliotecas:

==29997== 1,512 bytes in 3 blocks are possibly lost in loss record 24 of 25 
==29997== at 0x4004B11: memalign (vg_replace_malloc.c:532) 
==29997== by 0x4004B6B: posix_memalign (vg_replace_malloc.c:660) 
==29997== by 0x5E9AC4: ??? (in /lib/libglib-2.0.so.0.1200.3) 
==29997== by 0x5EA4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)

Más abajo en la pila de llamadas, siempre hay una llamada a una función simplista, como g_key_file_new(), g_slist_prepend(), g_strsplit(), g_key_file_load_from_file(), g_file_get_contents().

Mis preguntas son:

Alguien ha encontrado con esto y encontraron una manera de evitarlo?
¿O es algo que no puedo tener en cuenta? ¿Se debe a glib usando pools de memoria, como se sugiere here?

estoy usando

valgrind-3.5.0
simplista-2.12.3
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
CentOS versión 5.5 (final)

Fuente

2010-11-23 ttreitlinger

GLib tiene algunas características que confunden Valgrind.

Una son las agrupaciones de memoria (g_slice en glib más reciente, "mem chunks" en versiones anteriores). Se trata de asignadores especializados que se utilizan para objetos pequeños, como los nodos de lista. Puede usar esto para deshabilitar el asignador de sectores: G_SLICE=always-malloc valgrind myprogram

Un segundo problema es que a veces GLib evitaría inicializar memoria nueva o mantener los punteros muertos en segmentos/fragmentos liberados. Puedes solucionar este problema con: G_DEBUG=gc-friendly valgrind myprogram

Así que juntos, por supuesto: G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogram

Un tercer problema es que GLib tiene variables globales que están simplemente nunca liberaron pero considerados estado del programa permanente. Por ejemplo, el GType registrado nunca se descarga, y algunos otros. Esto no es reparable, pero valgrind debería mostrar estas asignaciones globales como alcanzables, en lugar de como perdidas.

Fuente

2010-11-23 14:28:53

Ejecutando el programa con G_SLICE = siempre-malloc no muestra memoria perdida, lo cual confirma mi sospecha de que toda (posible) pérdida de memoria se produce debido a la acumulación de memoria. Gracias Havoc P por la respuesta clara. – ttreitlinger

Havoc ¿puede confirmar que su afirmación sobre las variables globales sigue siendo cierta para GLib 2.32? ¡Gracias! –

sí, por ejemplo en gconvert.c "static GHashTable * iconv_cache" etc. (solo un ejemplo) –

simplista-2.12 es bastante antiguo.

Intente obtener glib-2.24, compile e instálelo (con --prefix =/usr/local/glib-2.24 por ejemplo) y úselo para compilar su aplicación.

Si todavía tiene esto, tratar de leer el manual simplista de nuevo :)

Fuente

2010-11-23 09:54:22 Guillaume

Lamentablemente estoy atascado con esta versión de glib, ya que el software que estoy desarrollando se ejecutará en un servidor administrado, con 2.12 siendo la versión predeterminada – ttreitlinger

Valgrind informa que la memoria 'posiblemente se ha perdido' cuando se usan tipos de datos glib

Respuesta

Cuestiones relacionadas