Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 58

Biuletyn 58

by Z98 on 2009-05-16
translated by Mariusz Przybylski on 2009-05-28

Tłumaczenie: Mariusz Przybylski

UniATA

Sterownik Universal ATA często uznawany był za sposób na rozwiązanie pewnych drażniących problemów w ReactOS, jak na przykład braku obsługi SATA i ograniczenia ilości miejsca widzianego przez ROS do około 8GB. Ponieważ oba problemy w dzisiejszych czasach graniczą z absurdem, rozwiązanie ich miało bardzo wysoki priorytet. Na drodze do przesiadki stało jednak parę błędów, z których część udało się naprawić Aleksiejowi Braginowi. Największym z nich było niewykrywanie przez UniATA napędu CD-ROM na rzeczywistym sprzęcie, czego przyczynę Aleksiej ustalił na błędy w opóźnieniach czasowych. Deweloper UniATA postanowił zmniejszyć czas oczekiwania na niektóre operacje, na skutek czego kontrolery nie mogły zdążyć ze zmianą swojego stanu. Aleksiej wydłużył czas oczekiwania do wartości ze starego sterownika atapi, dzięki czemu napędy są teraz poprawnie wykrywane na rzeczywistym sprzęcie.

Innym błędem, który nie został jeszcze naprawiony, jest awaria UniATA na VirtualBox. Przyczyna wciąż jest niejasna, ale będzie następną na liście Aleksieja.

Pula pamięci

Szukając przyczyny naruszenia spójności danych, Aleksiej sprawdził jak dokładnie używana jest pula pamięci. Pula jest sposobem na alokację pamięci przez jądro i sterowniki. Może być zarówno stronicowana (zapisywana na dysku) jak i niestronicowana (zawsze w pamięci). Aleksiej pracował nad nową implementacją a w międzyczasie napisał debugera puli pamięci, zdolnego śledzić przecieki w odczycie i zapisie do zaalokowanych już pul. Za pomocą tego debugera znalazł tylko jeden problem z odczytem w menadżerze PnP (over-read). Narzędzie nie sprawdza pod kątem błędów under-read i under-write, więc mogą jeszcze tkwić w kodzie. Jednak dzięki niemu zespół będzie mógł ustrzec się przed podobnymi błędami w przyszłości. Jest to część prac nad nową implementacją puli pamięci, nad którą Aleksiej pracował, lecz nie mógł opublikować, ze względu na to, że zwiększa ryzyko awarii. Miejmy nadzieję, że Aleksiej za pomocą debugera zdoła wyśledzić ich przyczynę.

Aleksiej był też za debugerem sterty (ang. heap), jednak to może okazać się kłopotliwe w realizacji, ze względu na to, że alokacje sterty są o wiele częstsze.

Na marginesie Aleksiej naprawił też jeden z problemów USB, który powodował awarie na rzeczywistym sprzęcie. Kod USB usiłował usunąć wskaźnik z nieistniejącej listy wiązanej, co prowadziło do uszkodzenia puli pamięci. Jest to przykład błędu under-write, którego debuger puli jeszcze nie wykrywa.

Więcej pamięci

W trakcie naprawiania błędu który ujawnił się przy OllyDbg, Michael Martin przypadkowo naprawił również instalację Mono. Dokładne powody dlaczego zarówno OllyDbg jak i Mono dotknięte były tym błędem nie są jasne, jednak Michael jest pewien, że błąd ten został usunięty. Błąd polegał na tym, że OllyDbg wywoływał serię funkcji, poczynając od CreateFileMappingA. Interesującą rzeczą jest tu wielkość, w oparciu o którą następowała alokacja pamięci. OllyDbg wywoływał później MapViewOfFile i w tym miejscu pojawiały się problemy. Funkcja MapViewOfFile oraz funkcje przez nią wywoływane szukały struktury SEC_IMAGE, która była lub też nie była definiowana przez CreateFileMapping i jej funkcje podrzędne. Jeśli MapViewOfFile znalazła tą strukturę, to wielkość w niej określoną zaokrąglała do wielkości strony pamięci. Gdy natomiast SEC_IMAGE nie znalazła, to wielkość sciągała ze struktury FileObject, tworzonej przez łańcuch wywołań CreateFileMapping. Wartość ta jednak nie była zaokrąglana w górę. Prowadziło to do problemów, gdy OllyDbg wywoływał trzecią z kolei funkcję, VirtualQuery. Dostarczała ona informacji na temat obszaru pamięci, wliczając w to jego wielkość. OllyDbg najwyraźniej spodziewał się wielkości zrównanej do rozmiaru strony i źle odbierał wartość niezrównaną.

Z początku Michael nie zdawał sobie sprawy z tego, że zaokrąglanie nie miało miejsca. Przeprowadził parę testów na Windows XP gdzie zauważył, że VirtualQuery zawsze zwracała wielkość zrównaną z wielkością strony pamięci. Wykonał więc śledzenie wsteczne (ang. Backtracking) w ReactOS, by znaleźć miejsce w którym wyrównywanie nie było przeprowadzane i znalazł błąd. Nikt nie jest do końca pewien w jaki sposób miało to wpływ na Mono, bo nikt nie podjął się sprawdzenia bezpośredniej przyczyny jego awarii. Testerzy jednak są zgodni co do faktu, że po tej poprawce Martina mogli z powodzeniem Mono zainstalować.