Przejdź do głównej zawartości

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).

Popularne posty z tego bloga

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekaz…