Debugger nie zatrzymuje się na breakpointach

Debugger nie zatrzymuje się na breakpointach wskazuje na niedopasowane symbole debugowania (pliki PDB) do wersji kompilowanego kodu — trzeba przebudować projekt z aktualnymi symbolami.

Czym jest problem z zatrzymywaniem debuggera na breakpointach

Komunikat lub zachowanie opisane jako „Debugger nie zatrzymuje się na breakpointach” oznacza, że uruchamiany program przechodzi przez miejsce oznaczone punktem przerwania bez otwarcia sesji debugowania w oczekiwanym wierszu kodu. Breakpoint może być widoczny w edytorze, lecz podczas działania aplikacji pozostaje nieaktywny albo zostaje pominięty. Nie musi to oznaczać awarii samego debuggera. Częściej wskazuje na rozbieżność między kodem oglądanym w środowisku programistycznym a plikiem wykonywalnym faktycznie uruchomionym przez system.

Jedną z głównych przyczyn jest niedopasowanie symboli debugowania do wersji skompilowanego programu. Dla wielu aplikacji tworzony jest osobny plik z informacjami pozwalającymi powiązać instrukcje maszynowe z nazwami funkcji, numerami wierszy i zmiennymi widocznymi w kodzie źródłowym. W środowisku opartym na technologii .NET taką rolę mogą pełnić pliki PDB. Jeżeli plik wykonywalny pochodzi z innej kompilacji niż plik symboli, debugger może nie potrafić prawidłowo przypisać breakpointu do instrukcji, mimo że kod wygląda poprawnie w projekcie.

W praktyce punkt przerwania może być oznaczony jako niezaładowany, nieaktywny lub pozostawać wizualnie dostępny bez faktycznego działania. W takiej sytuacji konieczne bywa wyczyszczenie wcześniejszych artefaktów kompilacji, ponowne zbudowanie projektu oraz uruchomienie właściwej konfiguracji debugowej. Znaczenie ma także to, czy sesja korzysta z aktualnego katalogu wynikowego, właściwego procesu i tego samego pliku źródłowego, który był użyty podczas kompilowania programu.

Kontekst techniczny i porównanie możliwych przyczyn - Debugger nie zatrzymuje się na breakpointach

Breakpoint działa na styku kilku elementów: kodu źródłowego, kompilatora, pliku wykonywalnego, symboli debugowania oraz procesu uruchomionego przez debugger. Zerwanie zgodności choćby jednego z nich może spowodować pominięcie punktu przerwania. Najczęściej występuje sytuacja, w której po zmianie kodu uruchamiany jest starszy plik wynikowy. Podobny efekt może powstać po skopiowaniu programu z innego katalogu, zmianie konfiguracji z debugowej na produkcyjną albo pozostawieniu w folderze wynikowym symboli utworzonych wcześniej.

Warto odróżnić problem z breakpointem od błędu w przepływie programu. Jeśli wykonywanie nie dochodzi do danej funkcji, punkt przerwania również nie zostanie osiągnięty, nawet gdy symbole są prawidłowe. Przyczyną może być inna ścieżka warunkowa, wcześniejsze zakończenie metody, wyjątek przechwycony przez kod aplikacji albo pominięcie fragmentu przez optymalizację. Jeżeli breakpoint znajduje się wewnątrz instrukcji warunkowej, trzeba sprawdzić, czy warunek rzeczywiście przyjmuje wartość prowadzącą do tego miejsca.

Osobnej uwagi wymaga breakpoint warunkowy. Dodatkowe wyrażenie ograniczające zatrzymanie może nigdy nie zostać spełnione, a nieprawidłowe ustawienie liczby trafień może sprawiać wrażenie, że debugowanie nie działa. Podobnie działa breakpoint ustawiony w kodzie, który nie jest aktualnie wykonywany, na przykład w nieużywanej implementacji interfejsu lub w bibliotece wczytanej w innej wersji. W aplikacjach wielowątkowych zatrzymanie może nastąpić na innym wątku niż oczekiwany, przez co obserwowany przebieg wydaje się niespójny.

Porównanie daty modyfikacji pliku wykonywalnego, symboli i źródeł często pozwala szybko zawęzić obszar poszukiwań. Należy również sprawdzić, czy debugger wskazuje właściwy proces oraz czy moduł zawierający badany kod został załadowany. Samo otwarcie pliku projektu nie gwarantuje, że uruchomiono program z tego samego środowiska, konfiguracji i ścieżki wyjściowej.

Typowe problemy i błędy prowadzące do pomijania breakpointów

Najczęściej stosowanym błędem jest wielokrotne uruchamianie kompilacji bez usunięcia starych plików wynikowych. W katalogu mogą wtedy pozostać elementy należące do różnych wersji projektu. Debugger otrzymuje kod źródłowy z jednej kompilacji, plik wykonywalny z drugiej i symbole z jeszcze innej. Rezultatem jest brak zatrzymania, zatrzymanie w nieoczekiwanym miejscu albo komunikat o niemożności odnalezienia odpowiedniego kodu.

Problemy mogą być także związane z konfiguracją budowania. Ustawienia ograniczające generowanie symboli, włączona optymalizacja, nieprawidłowy profil uruchomieniowy lub wskazanie innego projektu startowego wpływają na to, jakie informacje są dostępne podczas sesji. W przypadku aplikacji korzystających z bibliotek trzeba upewnić się, że używana biblioteka została ponownie zbudowana i że proces nie ładuje kopii przechowywanej w innym katalogu.

Do częstych pomyłek należy również ustawienie breakpointu w kodzie, który został usunięty, przeniesiony albo zastąpiony przez inną implementację. Edytor może zachować oznaczenie punktu przerwania, lecz po zmianie struktury pliku jego położenie nie musi odpowiadać instrukcjom wykonywanym przez program. Warto usunąć stare breakpointy i ustawić je ponownie po zakończeniu kompilacji.

Jeżeli punkt przerwania jest osiągany tylko pod określonym warunkiem, pomocne bywa tymczasowe usunięcie warunku i umieszczenie breakpointu na początku metody. Pozwala to rozdzielić dwa problemy: brak dotarcia do kodu oraz brak poprawnego mapowania symboli. Należy także przeanalizować log uruchomienia, listę załadowanych modułów, wybrany proces i moment, w którym następuje wczytanie badanej biblioteki.

Przydatna jest metodyczna kolejność działań: zatrzymanie działającej sesji, zamknięcie środowiska, usunięcie nieaktualnych artefaktów kompilacji, pełna przebudowa projektu, sprawdzenie konfiguracji debugowania i ponowne uruchomienie właściwego programu. Jeżeli problem pozostaje, trzeba ustalić, czy błąd dotyczy jednego pliku, całego projektu, konkretnej konfiguracji czy konkretnego komputera. Takie rozróżnienie ogranicza ryzyko wprowadzania przypadkowych zmian w kodzie.

W jakich sytuacjach warto oddać urządzenie do diagnozy - Debugger nie zatrzymuje się na breakpointach

Zgłoszenie do serwisu może być uzasadnione wtedy, gdy breakpointy przestały działać po zmianie systemu, aktualizacji środowiska programistycznego, przeniesieniu projektu albo wymianie podzespołów. Szczególnej uwagi wymaga sytuacja, w której problem występuje równocześnie z samoczynnym zamykaniem aplikacji, niestabilnością systemu, błędami odczytu plików lub nieprawidłowym działaniem wielu niezależnych programów. Wtedy przyczyna może wykraczać poza ustawienia debuggera i obejmować konfigurację środowiska, uprawnienia, uszkodzone pliki lub błędnie wskazane ścieżki.

Przed przekazaniem sprzętu warto przygotować nazwę używanego środowiska, informację o konfiguracji uruchomieniowej, opis chwili, od której występuje problem, oraz przykład funkcji, w której debugger nie zatrzymuje się zgodnie z oczekiwaniem. Pomocne jest także zachowanie komunikatów o niezaładowanych symbolach i wskazanie, czy problem dotyczy wszystkich projektów, czy tylko jednego. Dzięki temu łatwiej oddzielić błąd aplikacji od problemu z komputerem lub jego konfiguracją.

W Warszawie ocenę takiego przypadku można zlecić firmie Serwis laptopów i komputerów PC - Warszawa, gdzie wstępna diagnoza laptopa jest darmowa. Podczas sprawdzania można zweryfikować stan systemu, dostęp do plików projektu, zgodność konfiguracji debugowania oraz poprawność uruchamiania procesu. Jeżeli źródło problemu leży w samym projekcie, wyniki kontroli mogą pomóc w przekazaniu programiście konkretnych informacji o modułach, ścieżkach i wersjach plików.

Warto zgłosić się po pomoc również wtedy, gdy ponowna kompilacja nie przynosi rezultatu, breakpoint działa tylko sporadycznie albo zatrzymanie następuje w innym miejscu niż wskazany kod. Takie objawy mogą wynikać z kilku nakładających się przyczyn, których rozdzielenie wymaga sprawdzenia całego łańcucha: od plików źródłowych i symboli, przez konfigurację środowiska, aż po uruchomiony proces i stan systemu.