Segfaulting tylko bez valgrind

Question

otrzymam ostateczną „Gotowe” wiadomość z valgrind, a otrzymasz ten raport Wyjście:

==3434== HEAP SUMMARY: 
==3434==  in use at exit: 8,432 bytes in 4 blocks 
==3434== total heap usage: 4,369 allocs, 8,037 frees, 377,356 bytes allocated 
==3434== 
==3434== LEAK SUMMARY: 
==3434== definitely lost: 152 bytes in 1 blocks 
==3434== indirectly lost: 0 bytes in 0 blocks 
==3434==  possibly lost: 0 bytes in 0 blocks 
==3434== still reachable: 8,192 bytes in 2 blocks 
==3434==   suppressed: 88 bytes in 1 blocks 
==3434== Rerun with --leak-check=full to see details of leaked memory 
==3434== 
==3434== For counts of detected and suppressed errors, rerun with: -v 
==3434== ERROR SUMMARY: 100190 errors from 140 contexts (suppressed: 0 from 0) 

Ale kiedy go uruchomić bez valgrind, zwraca błąd natychmiast. Czy valgrind tłumi pewien rodzaj błędu, którego powinienem szukać? Nie mogę znaleźć żadnych informacji na ten temat w Internecie

Answer 1

Valgrind uruchamia program w innym środowisku niż w przypadku uruchamiania z powłoki. Może to zapobiec pewnym awariom w przypadku wyczerpania pamięci lub wychodzenia z tablicy.

Popraw 140 kontekstów błędów, a wszystko będzie w porządku.

Answer 2

Memcheck nie wykonuje pełnego sprawdzenia granic i ponieważ ma własny alokator pamięci, może tłumić błędy, które w przeciwnym razie dostałbyś. Zamiast tego użyj debuggera.

Answer 3

Jednym z przykładów błędu, który czasami nie jest przechwytywany przez Valgrind, jest zwolnienie pamięci, a następnie odniesienie jej przez inny wskaźnik, który również wskazywał to samo miejsce.

Nie jestem pewien, dlaczego tak się dzieje. Być może środowisko Valgrind w różny sposób obsługuje alokację i alokację pamięci. [Tak jak mówi Eregrith]

Szybkim sposobem sprawdzenia tego byłoby tymczasowe skomentowanie twoich bezpłatnych wywołań funkcji() i sprawdzenie, czy nadal jest to uszkodzenie. [Odkomentuj je później, gdy je naprawisz!]