Jaki jest najlepszy sposób na poszukiwanie dziur w pamięci?

pytanie zadane 13 lutego 2016 w C i C++ przez emSon Stary wyjadacz (10,480 p.)

Cześć. Prawie ukończyłem proces tworzenia mojej gry. Jednak znajduje się masa luk w kodzie powodująca crashe i wyjątki. Nie mam pojęcia gdzie są, a proces debugowania wskazuje zwykle na mało znaczące wartości w kodzie jak na przykład:

while(window->pollEvent(event)){...}

Nie używam tablic, a jedynie wektory. Upewniłem się, że nie odwołuje się do nieistniejącego elementu:

for(size_t i=0; i<parties.size(); i++)

Jak mogę znaleźć linie kodu, które powodują te błędy? Nie mogę określić dokładnie jakie funkcje je powodują, ponieważ często gra crashuje się w losowym momencie, albo przy n-tym odpaleniu.

Jeszcze przy okazji, dlaczego działanie programów skompilowanych w trybie debug i release przez jest różne? Bardzo często w release nie rysuje mi się jeden obiekt, a w debug nie ma takiego problemu.

3 odpowiedzi

odpowiedź 13 lutego 2016 przez Waszek Gaduła (4,130 p.)

Program Valgrind - służy do szukania dziur w pamięci. W sensie czy poprawnie nią zarządzamy itd.

komentarz 13 lutego 2016 przez emSon Stary wyjadacz (10,480 p.)

mam go. wyłożył 100 linii błędów.

komentarz 13 lutego 2016 przez draghan VIP (106,230 p.)

emSon: No to do pracy. ;)

odpowiedź 13 lutego 2016 przez MetGang Nałogowiec (34,360 p.)

Z taką ilością kodu trudno będzie znaleźć konkretny problem. Używasz gdzieś jakiś timerów, modulo, dzielenia, wskaźników?

komentarz 13 lutego 2016 przez emSon Stary wyjadacz (10,480 p.)

całość ma ok. tysiąc lini. tak, używam. pytam o teorię.

komentarz 13 lutego 2016 przez MetGang Nałogowiec (34,360 p.)

Przy modulo/dzieleniu przez 0 łatwo wywalić cały program. Może jakaś zmienna się dekrementuje/inkrementuje i jest dzielnikiem.

Wskaźniki to wiadomo. Możesz zrobić makro, które testuje wskaźnik, czy jest on nullptr'erem. __LINE__ pokazuje linie wywołania, __FILE__ plik wywołania. Tak możesz łatwo namierzyć błąd.

Osobiście miałem taki problem z timerem, że gdy było mało kodu przed, czyli program był za szybki - jakaś zmienna nie zdążyła się zmienić i miałem bodajże dzielenie przez zero.

I taka kwestia odnośnie wywalania programu. Warto przebudowywać cały projekt, gdyż czasami może nagromadzić się jakiś śmieciowy kod.

odpowiedź 13 lutego 2016 przez criss Mędrzec (172,590 p.)

Powrzucaj w kod cout-y. Najlepiej przed i po każdej podejrzanej linijce. Jeśli debugger pokazuje SIGSEGV (mozliwe, że zrobiłem literówke), to celuj w iteracje po vectorach, tablicach itd. Jeśli używasz gdzieś czystych wskaźników (tzn. nie shared_ptr), upewnij się, że zawsze wskazują tam gdzie trzeba.

"Zakomentowywanie" linii w połączenie z tymi cout-ami zawsze prędzej czy później doprowadzało mnie do błedu.

Z tego co pokazuje debugger (funkcja powodująca crash) nie da się niczego wywnioskować? Co konkretnie pokazuje?