Mam pewien projekt i wycieka gdzieś w nim pamięć... ale nie mogę zlokalizować miejsca gdzie.
Na dodatek dzieją się dziwne rzeczy przy pierwszych parunastu iteracjach - o co chodzi, że wtedy zużycie pamięci wzrasta, a potem już to się nie dzieje?
CLion, OSX El Capitan.
Parę słów o programie - na potrzeby testów menu przerobiłem do formy
void showMenu(void)
{
Graph_t *graph;
for(int i = 0; i < 100; ++i)
{
graph = graphCreation();
updateDataBaseFile(graph);
removeGraph(graph);
}
}
Następnie szedłem debugerem krok po kroku i co iterację sprawdzałem ilość zajętego ramu w menedżerze. Uzyskałem takie wyniki (co iterację, w KB):
576 628 644 648 656 656 656 ... 10 kolejnych iteracji ... 664 ... 20 kolejnych iteracji ... 664 ... 20 kolejnych ... 664
To co mnie zastanawia, to fakt, czemu przez pierwsze ~15 iteracji był wyciek pamięci, a potem już nie.
Po uruchomieniu normalnie i większej ilości iteracji:
http://prnt.sc/b4wcb9
http://prnt.sc/b4wcgs
Jak widać potem wycieku nie ma.
Sprawdzając funkcje odpowiadające za usuwanie dynamicznych obiektów z pamięci, również nic nie znalazłem.
Z kolei wykorzystując narzędzie Valingrad dla 100 iteracji, otrzymałem następujący wynik:
==38912== HEAP SUMMARY:
==38912== in use at exit: 22,451 bytes in 188 blocks
==38912== total heap usage: 50,268 allocs, 50,080 frees, 2,433,819 bytes allocated
==38912==
==38912== Searching for pointers to 188 not-freed blocks
==38912== Checked 9,805,504 bytes
Oraz pewne wycieki pamięci:
==38912== 513 bytes in 1 blocks are definitely lost in loss record 52 of 62
==38912== at 0x100010D81: malloc (vg_replace_malloc.c:303)
==38912== by 0x1001FC66C: __parsefloat_buf (in /usr/lib/system/libsystem_c.dylib)
==38912== by 0x1001FA9EF: __svfscanf_l (in /usr/lib/system/libsystem_c.dylib)
==38912== by 0x1001EE492: fscanf (in /usr/lib/system/libsystem_c.dylib)
==38912== by 0x100002138: createLists (ListCreation.c:87)
==38912== by 0x1000017DD: graphCreation (GraphCreation.c:82)
==38912== by 0x10000177D: showMenu (Menu.c:62)
==38912== by 0x100001753: main (main.c:25)
I tip jest taki, że rzecz się dzieje przy fscanfie w funkcji createLists, która zostaje wywołana w funkcji graphCreation.
Parę słów o funkcjach - pierwsza tworzy listy, do których zostają wczytywane połączenia pomiędzy miastami z pliku (stąd się pojawia fscanf), a potem następuje powrót do graphCreation i zostają one dodane do grafu (wcześniej graf jest dynamicznie alokowany).
updateDataBaseFile aktualizuje plik z połączeniami (normalnie w programie jest menu, gdzie można edytować te połączenia).
removeGraph oczywiście usuwa cały graf z pamięci.
Co oznacza narastanie zużycia pamięci na początku? Przeglądając usuwanie grafu nie znalazłem tam żadnego błędu, a jeśli by był - to przecież rosłoby zużycie pamięci po tych 100k iteracjach.
C 