Sprawdzanie granic

Sprawdzanie granic
Deweloperzy	Mikrofokus
Wersja stabilna	12.1.40 / 5 marca 2021 r
System operacyjny	Okna
Typ	Profiler / debugger pamięci
Licencja	Własne oprogramowanie
Strona internetowa	www .microfocus.com / products /devpartner /

BoundsChecker to narzędzie do sprawdzania pamięci i sprawdzania poprawności wywołań API używane do tworzenia oprogramowania C++ z Microsoft Visual C++ . Został stworzony przez firmę NuMega na początku lat 90. Kiedy NuMega została zakupiona przez Compuware w 1997 roku, BoundsChecker stał się częścią większego pakietu narzędzi, DevPartner Studio . Micro Focus kupił linię produktów od Compuware w 2009 roku. Porównywalne narzędzia to Purify , Insure++ i Valgrind .

BoundsChecker można uruchomić w dwóch różnych trybach: ActiveCheck , który będzie działał z dowolną aplikacją w takiej postaci, w jakiej jest, lub FinalCheck , który korzysta z oprzyrządowania dodawanego do aplikacji podczas jej tworzenia.

ActiveCheck przeprowadza mniej inwazyjną analizę i monitoruje wszystkie wywołania przez aplikację biblioteki C Runtime Library , Windows API oraz wywołania obiektów COM . Monitorując alokacje i wydania pamięci , może wykrywać wycieki pamięci i przepełnienia. Monitorowanie wywołań API i COM umożliwia ActiveCheck sprawdzanie parametrów, zwrotów i wyjątków oraz zgłaszanie wyjątków, gdy wystąpią. Zakleszczenia wątków można również wykrywać poprzez monitorowanie obiektów synchronizacji i wywołań dających rzeczywiste i potencjalne wykrywanie zakleszczeń.

FinalCheck wymaga oprzyrządowanej kompilacji i zapewnia znacznie głębszą, ale bardziej inwazyjną analizę. Zapewnia wszystkie funkcje wykrywania ActiveCheck oraz możliwość wykrywania przepełnień bufora (odczyt i zapis) oraz niezainicjowanych dostępów do pamięci . Monitoruje każdą zmianę zakresu i śledzi wskaźniki odnoszące się do obiektów pamięci.

Ogólna funkcjonalność

Wykrywanie wycieków

Śledzenie pamięci — alokacja i zwalnianie pamięci jest śledzone przez cały okres eksploatacji aplikacji, a na koniec sesji generowany jest raport pokazujący, które bloki pamięci przydzielone przez kod użytkownika pozostają przydzielone w momencie normalnego zakończenia procesu. Gdy używana jest instrumentacja kompilatora, niektóre wycieki pamięci mogą zostać ogłoszone wcześniej, gdy ostatni wskaźnik odnoszący się do przydzielonej pamięci bloku wychodzi poza zakres lub zostaje nadpisany inną wartością. Poprzez te same mechanizmy zgłaszane są próby wykorzystania wskaźników do wcześniej zwolnionej pamięci.
Śledzenie obiektów COM — tworzenie i niszczenie obiektów COM jest śledzone przez cały okres eksploatacji aplikacji, a na koniec sesji generowany jest raport pokazujący, które obiekty pozostają aktywne w momencie normalnego zakończenia procesu.
Śledzenie zasobów — tworzenie i niszczenie uchwytów obiektów systemowych (takich jak uchwyty plików, uchwyty GDI itd.) jest monitorowane i generowany jest raport na koniec sesji pokazujący, które uchwyty pozostają w czasie normalnego zakończenia procesu.

Walidacja wywołań API

Wywołania API są monitorowane, ich parametry wejściowe weryfikowane przed faktycznym wykonaniem wywołań funkcji, ostrzegając o ewentualnych problemach. Kody powrotu API są również monitorowane, a kody błędów są rejestrowane. Taka walidacja jest ograniczona do takich interfejsów API, które są znane BoundsChecker, a obecnie jest ich kilka tysięcy. Jeśli śledzenie pamięci jest włączone, walidacja wywołania interfejsu API może wykorzystywać zebrane informacje do dokładniejszego sprawdzania poprawności wskaźników pamięci.

Wykrywanie przepełnienia pamięci

Gdy włączone jest zarówno śledzenie pamięci, jak i sprawdzanie poprawności interfejsu API, możliwe staje się wykrycie wielu rodzajów warunków przepełnienia tablicy i bufora. Instrumentacja kompilatora zwiększa tę zdolność. Jest to funkcja, dla której produkt został pierwotnie nazwany.

Rejestrowanie wywołań API

Wywołania interfejsów API, metod COM i funkcji .NET Interop można szczegółowo rejestrować, odnotowując wartości parametrów wywołania i wynikowe wartości zwracane. Ta funkcja ma ograniczoną wartość, ponieważ nietrywialne aplikacje często powodują, że dziennik sesji szybko staje się zbyt duży.

Analiza .NET

Można wygenerować raport analizujący działanie .NET Interop, wyrzucania elementów bezużytecznych i finalizatora przez cały czas trwania testowanego procesu.

Analiza impasu

Można wykryć pewne rodzaje śmiercionośnych uścisków i innych tego typu zamknięć.

Zgodność

Bieżąca wersja (12.1.40) BoundsChecker obsługuje natywne aplikacje 32-bitowe i 64-bitowe w systemie Windows 10 (aktualizacja wiosenna 2020). Środowiska MS-DOS, 16-bitowe systemy Windows, Windows 2000, Windows XP i Windows 7 nie są już obsługiwane. W ramach DevPartner Studio produkt integruje się z 2017 Update 15.9.33 i 2019 Update 16.9

Od marca 2021 r. funkcja analizy zakleszczeń nie jest jeszcze obsługiwana w aplikacjach X64.

Krytyka

Licencjonowanie — od czasu przejęcia przez Micro Focus International , pakiet spotkał się z krytyką ze względu na coraz bardziej niewygodne mechanizmy licencjonowania, z którymi należy się uporać podczas instalacji i używania. Na przykład każda recenzja na stronie sklepu internetowego sprzedającego produkt (oprócz jednej przesłanej przez jednego z jego programistów) opisuje produkt jako faktycznie bezużyteczny ze względu na sposób obsługi licencji.
Szybkość — jest to stosunkowo uciążliwe narzędzie, które może spowolnić testowaną aplikację od 50 do 300 razy. Im więcej funkcji jest używanych jednocześnie, tym wolniej. Jest to szczególnie prawdziwe w przypadku korzystania z oprzyrządowania kompilatora.
Waluta — chociaż produkt działa z wieloma wersjami systemu Windows i programu Microsoft Visual Studio, baza danych walidacji interfejsów API nie została znacząco dodana od 2006 r. Nowsze interfejsy API na ogół nie są monitorowane.
Przenośność — obsługiwane są tylko systemy Microsoft Windows i Microsoft Visual Studio. Nie ma wsparcia dla innych systemów operacyjnych ani kompilatorów.
Hałas — zgłaszanych jest wiele wyników, które, choć prawidłowe, nie są zbyt przydatne. Najczęstsze z tego rodzaju rzeczy to zwroty błędów interfejsu API. To zupełnie normalne, że niektóre wywołania API kończą się niepowodzeniem. Tego rodzaju wyniki można stłumić.

Historia wersji

12.0 — marzec 2020 r. — nowa wersja stworzona dla najnowszego środowiska uruchomieniowego Visual C/C++ firmy Microsoft. Wiele innych wewnętrznych zmian.
11.5.1 — wrzesień 2020 r. — teraz korzysta z instalatora WiX Toolset.
11.4 HF5 — luty 2020 r. — obsługa programu Visual Studio 2019 16.4.5. Ostatnia wersja obsługująca system Windows 7 lub starszy albo program Visual Studio 2015 lub starszy.
11.4 HF4 — październik 2019 r. — obsługa aktualizacji jesiennej systemu Windows 10 2019 i programu Visual Studio 2019 16.3.6.
11.4 HF3 — maj 2019 r. — obsługa aktualizacji wiosennej systemu Windows 10 2019 i programu Visual Studio 2019 16.0.3.
11.4 HF2 — grudzień 2018 r. — obsługa aktualizacji jesiennej systemu Windows 10 2018 i programu Visual Studio 2017 15.9.4.
11.4 — listopad 2017 r. — obsługa aktualizacji Fall Creator dla systemu Windows 10 2017.
11.3 HF5 — kwiecień 2017 r. — obsługa programu Visual Studio 2017.
11.3 — lipiec 2015 r. — obsługa systemu Windows 10 i programu Visual Studio 2015.
11.2 — styczeń 2014 r. — obsługa systemów Windows 8.1, Windows 8.0 i Visual Studio 2013.
11.1 - kwiecień 2013 - lokalizacja w języku chińskim (z wyłączeniem pomocy on-line). Różne poprawki błędów.
11.0 — wrzesień 2012 r. — pełna obsługa programu Visual Studio 2012, zwiększona wydajność i dokładność.
10.6 — kwiecień 2012 r. — nowy model licencjonowania, narzędzie do sprawdzania aktualizacji produktu, wstępna obsługa programu Visual Studio 2012 oraz narzędzie zasobnika systemowego z monitorem aktywności.
10.5 — luty 2011 r. — obsługuje aplikacje X64 w systemie Windows Vista X64 i nowszych.
10.0 — kwiecień 2010 r. — obsługuje program Visual Studio 2010.
9.1 — październik 2009 r. — obsługuje system Windows 7.
9.0 — wrzesień 2008 — obsługuje programy Visual Studios 2005 i 2008.
8.2 — maj 2007 — Ostatnia wersja z pełną obsługą Visual Studio 6.0 i Visual Studio .NET 2003.
6.0 - 1998 - Pierwsza wersja po przejęciu NuMega przez Compuware.
5.0 - marzec 1997
4.0 - 1996 - Wprowadzono funkcję sprawdzania poprawności interfejsu API.
2.0 dla systemu DOS — marzec 1991 r

Zobacz też