2015-01-08 14 views
5

Próbuję zintegrować odśmiecacz Boehm z GLib w Linuksie, ale w jednym przypadku stwierdziłem, że to nie zwalnia pamięci: kiedy wywołuję g_strsplit wiele razy, zabrakło pamięci i awarii. README dla odśmiecacza ostrzega, że ​​może mieć problem ze znalezieniem wskaźników wewnątrz dynamicznych bibliotek i może wymagać użycia GC_add_roots.Przeciek pamięci podczas korzystania ze zbierania śmieci za pomocą glib

Aby to sprawdzić, skopiowałem cały odpowiedni kod z GLib do mojego pliku źródłowego, nie łącząc się z libglib-2.0.so w ogóle. To wyeliminowało uszkodzenia, co mówi mi, że to rzeczywiście jest problem. Jednak nie ma dokumentacji dotyczącej sposobu użycia GC_add_roots do rozwiązania tego problemu. Czy ktoś może mi pomóc?

Oto kod, który powoduje wyciek pamięci:

#include <glib.h> 
#include <gc.h> 

void no_free(void *mem) {} 

int main() { 
    g_mem_gc_friendly = TRUE; 

    GMemVTable memvtable = { 
     .malloc  = GC_malloc, 
     .realloc  = GC_realloc, 
     .free  = no_free, 
     .calloc  = NULL, 
     .try_malloc = NULL, 
     .try_realloc = NULL 
    }; 

    g_mem_set_vtable(&memvtable); 

    for (int i = 0; i < 10000; i++) { 
     char **argv = g_strsplit("blah", " ", 0); 
     argv[0][0] = 'a'; // avoid unused variable warning 
    } 

    return 0; 
} 

Odpowiedz

1

Od GLib 2,46, g_mem_set_vtable() does nothing, więc nie ma sposobu, aby to działa na poziomie GLib wykorzystaniem nowoczesnego wygadany. GLib teraz bezwarunkowo używa alokatora z biblioteki libc, gdy wywołujesz g_malloc(), g_new() itd. Podczas jawnego używania g_slice_*() nadal używa własnego przydziału g_slice_*(), ale żąda przydziałów bloków również z przydziału libc.

Sugeruję, abyś spróbował zintegrować moduł do zbierania śmieci na poziomie libc. Jest an old article o implementacji tego przy użyciu glibc’s malloc hooks, które są zasadniczo takie same jak GMemVTable, ale na poziomie glibc zamiast poziomu GLib. Nie próbowałem tego, więc nie wiem, jak to działa w praktyce.

Powiązane problemy