Valgrind znajduje wycieki pamięci w programach uzywających GLib

December 19th, 2009 | by litestep |

Chcemy sprawdzić swój program i widzimy coś takiego:

#valgrind --leak-check=full ./a.out
==19197== 992 bytes in 2 blocks are possibly lost in loss record 9 of 10
==19197==    at 0x4C213A6: memalign (vg_replace_malloc.c:532)
==19197==    by 0x4C21402: posix_memalign (vg_replace_malloc.c:660)
==19197==    by 0x7ADFD80: ??? (in /lib/libglib-2.0.so.0.2200.3)
==19197==    by 0x7AE1622: g_slice_alloc (in /lib/libglib-2.0.so.0.2200.3)
==19197==    by 0x7A9E731: g_array_sized_new (in /lib/libglib-2.0.so.0.2200.3)
==19197==    by 0x400B73: iowait_init (iowait.c:6)
==19197==    by 0x400DFF: main (main.c:7)


Upewniamy się dwa razy – w programie zwalniamy poprawnie pamięć, więc co może być nie tak? Czy to błąd w Glib? Oczywiście nie – przyczyna jest bardzo prosta – GLib stara się optymalizować zarządzanie pamięcią i alokuje od razu większe bloki, które sam potem dzieli i przydziela, dzięki czemu nie jest potrzebnych tyle wywołań systemowych. Ale Valgrind się przy takich sztuczkach gubi. Na szczęście jest to znany problem a jego ominiecie jest bardzo proste – wystarczy zdefiniować dwie zmienne środowiskowe

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind  --leak-check=full ./a.out

a Glib przestanie się wtrącać w alokowanie i zwalnianie pamięci. Więcej informacji można znaleźć na http://live.gnome.org/Valgrind

Post a Comment