Mój program nie działa poprawnie. Wygląda na to, że utknął w nieskończonej pętli lub złej blokadzie/odblokowaniu muteksu. Ale nie mam pojęcia, gdzie jest błąd. Próbowałem używać gdb do debugowania.Użyj gdb, aby znaleźć miejsce, w którym utknął program
Nie mogę użyć polecenia backtrace gdb, ponieważ nie wyznaczam punktu przerwania. I nie mogę tego określić, ponieważ nie mam pojęcia, gdzie jest błąd.
Czy gdb ma instrument do śledzenia wstecznego "w locie"?
Nie mogę użyć polecenia backtrace gdb, ponieważ nie wyznaczam punktu przerwania.
Tak, możesz.
Wszystko, czego potrzebujesz, to gdzieś gorszy program (który jest debugowany).
Po pierwszym dołączeniu do programu GDB zatrzymuje wszystkie wątki i można sprawdzić, gdzie się znajdują. Później możesz trafić Ctrl-C i ponownie spojrzeć na wszystkie wątki. Przydatne polecenie w thread apply all where.
gdy czujesz, że jesteś w środku jakiejś pętli infinte podczas debugowania, sprawdź kod i po prostu
dokonać przerwania po tej ewentualnej pętli i starają się wychodzić, dostaniesz pomysł jeśli
przerwania dostał hit po tej pętli, także po tym można przeanalizować, co jest nie tak w zmiennej z tej części kodu lub ponownie uruchomić próbkę repro w gdb.
Uzyskaj identyfikator procesu z "ps -ef" swojego programu. Użyj dokładnie tej funkcji, w której się zawiesił, aby wydrukować ślad stosu wykonania.
Przykâadowa:
$ pstack PROCESS_PID
\#0 0x00000038cfaa664e in waitpid() from /lib64/libc.so.6
\#1 0x000000000043ed42 in ??()
\#2 0x000000000043ffbf in wait_for()
\#3 0x0000000000430bc9 in execute_command_internal()
\#4 0x0000000000430dbe in execute_command()
\#5 0x000000000041d526 in reader_loop()
\#6 0x000000000041ccde in main()
Jeżeli uważasz, że Twój kod jest zatrzymany, można nacisnąć 'Ctrl-C' włamać debugger, a następnie pokazać bactrace, badać zmienne itp stamtąd. –
'printf' to kolejna metoda debugowania, choć nie tak idealna jak użycie debuggera. –