Zbieramy użyteczne informacje w przypadku błędów w aplikacji
Ze względu na sposób paczkowania w Archu (a co za tym idzie wszystkich jego pochodnych, w tym Manjaro, jak również wszystkich systemów, które wykorzystują pacmana) użyteczne dla programistów informacje, w przypadku błędów aplikacji, zbiera się nieco inaczej.
Podstawowe informacje może dostarczyć uruchomienie programu w konsoli i sprawdzenie komunikatów, które w ten sposób uzyskujemy. Niekiedy będą to informacje użyteczne, np. że program nie potrafi znaleźć jakiejś biblioteki, niekiedy jednak program nie uruchamia się, bądź też w sposób niekontrolowany wyłącza, a terminal dostarcza nam jedynie suchej informacji o zrzucie pamięci itp. Jeśli taki wynik przedstawimy komukolwiek, kto zechce nam pomóc, to najczęściej będzie to bezwartościowa informacja, która nie jest w stanie nawet wyjaśnić, czy błąd tkwi w samym programie, czy jest związany z paczkowaniem, czy kompilacją. Nie będzie też wiadomo czy i w jaki sposób taką aplikację można naprawić. Z pomocą przychodzi uruchomienie programu poprzez gdb, który prawdopodobnie w systemie macie. Jeśli z jakiejś przyczyny się on nie znajduje, to musimy go zainstalować. Stosowna paczka również nazywa się gdb.
Wyposażeni w tego debbugera uruchamiamy podejrzany program:
gdb nazwa_programu
przy czym nazwa_programu to jest program wykonywalny (binarny), a nie skrypt powłoki, który go wywołuje. Nie sprawdzimy zatem poprzez wywołanie gdb chromium czy gdb libreoffice ani przeglądarki chromium, ani pakietu libreoffice. Próba uruchomienia takiego "programu" spowoduje jedynie wyświetlenie informacji:
"/usr/bin/nazwa_programu": not in executable format: File format not recognized
W takim przypadku musimy przeglądnąć znajdujący się w podanej ścieżce program będący w istocie skryptem wywołującym właściwy plik wykonywalny, odszukać go i tę nazwę (najczęściej z całą ścieżką wywołać w gdb. Dla przykładu, w przypadku chromium będzie to:
gdb /usr/lib/chromium/chromium
Wywołanie, poprzedzone krótką informacją o programie, skończy się przejściem do znaku zachęty gdb, który wygląda tak:
(gdb)
By wykonać wewnątrz gdb program, musimy go uruchomić. Wpisujemy albo run, albo samo r:
(gdb) r
Jeśli poddany inspekcji program zakończymy i ujrzymy informację:
[Inferior 1 (process LICZBA) exited normally]
(w miejscu LICZBA pojawią się jakieś cyfry), to działanie programu przebiega poprawnie, nie wywołuje on żadnych błędów.
Prawdopodobieństwo, że program działający wadliwie zwróci taką informację w gdb jest jednak znikome. Najczęściej ujrzymy wówczas informację, o jakiejś wadliwości, a sam program w sposób niekontrolowany zamknie się. Już wówczas dysponujemy jakąś informacją, ale najcenniejszą uzyskamy poprzez podanie tzw. backtrace. Uzyskujemy to wpisując bt po znaku zachęty gdb, czyli;
(gdb) bt
Uzyskaną w ten sposób informację możemy podać osobom, które odpowiedzialne są za paczkowanie. Winny one na podstawie tej informacji móc ocenić, czy proces paczkowania i kompilacji przebiegł prawidłowo, czy też nie i w zależności od tego albo będą w stanie naprawić paczkę, albo odesłać problem (i nas) do osób odpowiedzialnych za kod źródłowy.
Z tego typu informacjami najsensowniej zgłaszać problem na forum Archa, bądź jego bugzilli (jeśli paczka pochodzi z Archa, jeśli nie - w odpowiednich forach danej dystrybucji), pamiętając, że "paczki" z AUR nie są objęte wspieraniem przez Archa. W tym przypadku, jedyne miejsce to albo poinformowanie o tym bezpośrednio opiekuna paczki, albo stosowne miejsce na forum Archa. Jeśli informacje taką zgłosicie na naszym forum, to prawdopodobnie uzyskacie jedynie informację, że problem należy zgłosić u źródła.
Na koniec jeszcze informacja dla osób podejrzewających Plasmę (jej elementy) o błędy. W takim przypadku wywołanie w gdb plasmashell musimy poprzedzić jej "ubiciem", co uzyskamy wpisując:
kquitapp5 plasmashell
w przypadku Plasmy, czy
kquitapp5 kwin_x11
w przypadku KWin pracującego w Xach (proces w Waylandzie nazywa się kwin_wayland).
Podstawowe informacje może dostarczyć uruchomienie programu w konsoli i sprawdzenie komunikatów, które w ten sposób uzyskujemy. Niekiedy będą to informacje użyteczne, np. że program nie potrafi znaleźć jakiejś biblioteki, niekiedy jednak program nie uruchamia się, bądź też w sposób niekontrolowany wyłącza, a terminal dostarcza nam jedynie suchej informacji o zrzucie pamięci itp. Jeśli taki wynik przedstawimy komukolwiek, kto zechce nam pomóc, to najczęściej będzie to bezwartościowa informacja, która nie jest w stanie nawet wyjaśnić, czy błąd tkwi w samym programie, czy jest związany z paczkowaniem, czy kompilacją. Nie będzie też wiadomo czy i w jaki sposób taką aplikację można naprawić. Z pomocą przychodzi uruchomienie programu poprzez gdb, który prawdopodobnie w systemie macie. Jeśli z jakiejś przyczyny się on nie znajduje, to musimy go zainstalować. Stosowna paczka również nazywa się gdb.
Wyposażeni w tego debbugera uruchamiamy podejrzany program:
gdb nazwa_programu
przy czym nazwa_programu to jest program wykonywalny (binarny), a nie skrypt powłoki, który go wywołuje. Nie sprawdzimy zatem poprzez wywołanie gdb chromium czy gdb libreoffice ani przeglądarki chromium, ani pakietu libreoffice. Próba uruchomienia takiego "programu" spowoduje jedynie wyświetlenie informacji:
"/usr/bin/nazwa_programu": not in executable format: File format not recognized
W takim przypadku musimy przeglądnąć znajdujący się w podanej ścieżce program będący w istocie skryptem wywołującym właściwy plik wykonywalny, odszukać go i tę nazwę (najczęściej z całą ścieżką wywołać w gdb. Dla przykładu, w przypadku chromium będzie to:
gdb /usr/lib/chromium/chromium
Wywołanie, poprzedzone krótką informacją o programie, skończy się przejściem do znaku zachęty gdb, który wygląda tak:
(gdb)
By wykonać wewnątrz gdb program, musimy go uruchomić. Wpisujemy albo run, albo samo r:
(gdb) r
Jeśli poddany inspekcji program zakończymy i ujrzymy informację:
[Inferior 1 (process LICZBA) exited normally]
(w miejscu LICZBA pojawią się jakieś cyfry), to działanie programu przebiega poprawnie, nie wywołuje on żadnych błędów.
Prawdopodobieństwo, że program działający wadliwie zwróci taką informację w gdb jest jednak znikome. Najczęściej ujrzymy wówczas informację, o jakiejś wadliwości, a sam program w sposób niekontrolowany zamknie się. Już wówczas dysponujemy jakąś informacją, ale najcenniejszą uzyskamy poprzez podanie tzw. backtrace. Uzyskujemy to wpisując bt po znaku zachęty gdb, czyli;
(gdb) bt
Uzyskaną w ten sposób informację możemy podać osobom, które odpowiedzialne są za paczkowanie. Winny one na podstawie tej informacji móc ocenić, czy proces paczkowania i kompilacji przebiegł prawidłowo, czy też nie i w zależności od tego albo będą w stanie naprawić paczkę, albo odesłać problem (i nas) do osób odpowiedzialnych za kod źródłowy.
Z tego typu informacjami najsensowniej zgłaszać problem na forum Archa, bądź jego bugzilli (jeśli paczka pochodzi z Archa, jeśli nie - w odpowiednich forach danej dystrybucji), pamiętając, że "paczki" z AUR nie są objęte wspieraniem przez Archa. W tym przypadku, jedyne miejsce to albo poinformowanie o tym bezpośrednio opiekuna paczki, albo stosowne miejsce na forum Archa. Jeśli informacje taką zgłosicie na naszym forum, to prawdopodobnie uzyskacie jedynie informację, że problem należy zgłosić u źródła.
Na koniec jeszcze informacja dla osób podejrzewających Plasmę (jej elementy) o błędy. W takim przypadku wywołanie w gdb plasmashell musimy poprzedzić jej "ubiciem", co uzyskamy wpisując:
kquitapp5 plasmashell
w przypadku Plasmy, czy
kquitapp5 kwin_x11
w przypadku KWin pracującego w Xach (proces w Waylandzie nazywa się kwin_wayland).
Komentarze
Prześlij komentarz