28.12.2007 09:55
[#1]
Kontrolowana jazda po pamieci
Hi,
Zapytam o coś o czym była zapewne mowa tysiąc razy. Mowa o tym była pewnie wiele razy choćby przy zdawaniu bug-reportów dla autora AmiGG. Ale kurcze zapytam pomimo strachu przed zlinczowaniem. :)
Chodzi mi o to jak mogę sobie wykryć ewentualne niekontrolowane odczyty z czy zapisy do cudzej pamięci w jakimś programie. Coś tam sobie klepię (na razie pod MorphOS) i w pewnej sytuacji jest to dosyć niestabilne. Analizowałem wszystko wiele razy i wydaje mi się, że wszystko jest ok. Jednak chciałbym sie upewnić czy aby gdzieś niechcący nie przekroczyłem jakiejś tablicy czy nie odwołuję się do jakiegoś NULLa. :) Raczej jest to niemożliwe, bo mam zwyczaj bardzo uważnie (i niestety bardzo powoli) pisać. Ale wiemy jak to jest. Jakaś zmiana czasem wpływa nieprzewidywalnie na inne kawałki programu. :)
Wobec tego co napisałem chciałbym się dowiedzieć jak mogę przede wszystkim na MorphOS (ale potem może i na AmigaOS3) sprawdzić czy nie dotykam swoimi wypocinami cudzej pamięci? Jak uzyskać jakieś logi, jak z nich wyczytać co jest nie tak? Idealnie byłoby gdybym takie komunikaty mógł widzieć w czasie rzeczywistym. To znaczy żeby obok okna programu właściwego leciały mi w konsoli w przypadku gdy się coś nieprzewidzianego stanie. Jest to możliwe? Mógłby mi ktoś to jakoś tak os praktycznej strony szybko opisać? Obiecuję, że teraz z tego naprawdę skorzystam i więcej pytał o to nie będę. :D
MDW
Zapytam o coś o czym była zapewne mowa tysiąc razy. Mowa o tym była pewnie wiele razy choćby przy zdawaniu bug-reportów dla autora AmiGG. Ale kurcze zapytam pomimo strachu przed zlinczowaniem. :)
Chodzi mi o to jak mogę sobie wykryć ewentualne niekontrolowane odczyty z czy zapisy do cudzej pamięci w jakimś programie. Coś tam sobie klepię (na razie pod MorphOS) i w pewnej sytuacji jest to dosyć niestabilne. Analizowałem wszystko wiele razy i wydaje mi się, że wszystko jest ok. Jednak chciałbym sie upewnić czy aby gdzieś niechcący nie przekroczyłem jakiejś tablicy czy nie odwołuję się do jakiegoś NULLa. :) Raczej jest to niemożliwe, bo mam zwyczaj bardzo uważnie (i niestety bardzo powoli) pisać. Ale wiemy jak to jest. Jakaś zmiana czasem wpływa nieprzewidywalnie na inne kawałki programu. :)
Wobec tego co napisałem chciałbym się dowiedzieć jak mogę przede wszystkim na MorphOS (ale potem może i na AmigaOS3) sprawdzić czy nie dotykam swoimi wypocinami cudzej pamięci? Jak uzyskać jakieś logi, jak z nich wyczytać co jest nie tak? Idealnie byłoby gdybym takie komunikaty mógł widzieć w czasie rzeczywistym. To znaczy żeby obok okna programu właściwego leciały mi w konsoli w przypadku gdy się coś nieprzewidzianego stanie. Jest to możliwe? Mógłby mi ktoś to jakoś tak os praktycznej strony szybko opisać? Obiecuję, że teraz z tego naprawdę skorzystam i więcej pytał o to nie będę. :D
MDW
28.12.2007 10:16
[#3]
Re: Kontrolowana jazda po pamieci
@MDW, post #1
Odpowiedź jest dość zaskakująca, otóż dokładnie... nie da się tego wyśledzić. Możliwe są jedynie pewne półśrodki.
1. Mungwalling pamięci - otaczasz każdą alokację "ścianą" o zadanej grubości, wypełnioną zdefiniowanym wzorem. Przy zwalnianiu ściana sprawdzana jest, czy wzór nie został naruszony. Pod MOS-em wystarczy zlinkować program z reslib Morgotha - patchuje wszystkie systemowe funkcje alokacji, przy okazji wyłapuje błędne FreeMem()-y i inne takie. Niestety mungwalling wykrywa tylko i wyłącznie wyjechanie w pobliżu zaalokowanego obszaru (zależnie od grubości ściany), czyli typowe wyjechanie poza bufor, albo rzeczy w rodzaju buf[-1].
2. Invzeropage - jest to flaga przy bootowaniu MOS-a, która powoduje że pod adres 0 wpisywana jest wartość nie będąca prawidłowym adresem pamięci. Dzięki temu każda próba odwołania się do zerowego wskaźnika powoduje natychmiastowe wywalenie się programu i odpowiedniego hita w debuglogu. Niestety ta flaga chyba nie istnieje w publicznym kernelu MOS-a (proszę mnie poprawić jeżeli się mylę). Bez tej flagi pod adresem 0 jest przeważnie 0, co nie daje natychmiastowego przerwania programu, a może dawać różne dziwne efekty, bo np. odwołanie się do NULL-a z offsetem 4 da nam ExecBase...
1. Mungwalling pamięci - otaczasz każdą alokację "ścianą" o zadanej grubości, wypełnioną zdefiniowanym wzorem. Przy zwalnianiu ściana sprawdzana jest, czy wzór nie został naruszony. Pod MOS-em wystarczy zlinkować program z reslib Morgotha - patchuje wszystkie systemowe funkcje alokacji, przy okazji wyłapuje błędne FreeMem()-y i inne takie. Niestety mungwalling wykrywa tylko i wyłącznie wyjechanie w pobliżu zaalokowanego obszaru (zależnie od grubości ściany), czyli typowe wyjechanie poza bufor, albo rzeczy w rodzaju buf[-1].
2. Invzeropage - jest to flaga przy bootowaniu MOS-a, która powoduje że pod adres 0 wpisywana jest wartość nie będąca prawidłowym adresem pamięci. Dzięki temu każda próba odwołania się do zerowego wskaźnika powoduje natychmiastowe wywalenie się programu i odpowiedniego hita w debuglogu. Niestety ta flaga chyba nie istnieje w publicznym kernelu MOS-a (proszę mnie poprawić jeżeli się mylę). Bez tej flagi pod adresem 0 jest przeważnie 0, co nie daje natychmiastowego przerwania programu, a może dawać różne dziwne efekty, bo np. odwołanie się do NULL-a z offsetem 4 da nam ExecBase...
28.12.2007 10:21
[#5]
Re: Kontrolowana jazda po pamieci
@Grzegorz Kraszewski, post #4
Pozwala sledzic ewentualne hity. Od czegos nalezy zaczac. Dodatkowo część hitów u MDW może pochodzić z biblioteki standardowej, ta co jest oficjalnie rozprowadzana jest rzadko łatana, a ma troche za skórą, dlatego cały czas namawiam MDW do uzywania gcc by morgoth
28.12.2007 10:43
[#6]
Re: Kontrolowana jazda po pamieci
@Grzegorz Kraszewski, post #3
Dzięki za opisy dwóch dróg. Jak będzie trzeba to faktycznie chyba skorzystam z tego Mungwallingu. Jednak najpierw chciałbym się upewnić czy w ogóle latam po cudzej pamięci. Do tego wystarczy LogTool? Powie mi on jeżeli gdzieś (nie muszę wiedzieć gdzie) stało się coś co stać się nie powinno? Mogę sobie powtykać do programu jakieś takie debugowe printfy po którym będę mógł łatwiej zlokalizowac ewentualną przyczynę problemu? Jak uzyskać takie "wpisy"?
28.12.2007 10:46
[#7]
Re: Kontrolowana jazda po pamieci
@Kaczus, post #5
Przekonałeś mnie. :) Jak będą problemy to dotknę tego gcc Morgotha. :) Sposób instalacji tej wersji jest opisany w dokumentacji? Orientujesz się czy nie pokaszani mi to obecnego środowiska i wszystko w CubicIDE/GoldED będzie grało tak jak teraz?
Ostatnia modyfikacja: 28.12.07 10:46
Ostatnia modyfikacja: 28.12.07 10:46
28.12.2007 10:49
[#10]
Re: Kontrolowana jazda po pamieci
@Kaczus, post #8
Dzięki!
Sorry za lamerstwo ale naprawdę tego nie używałem i pojęcia nie mam. :) Tak sobie patrzę na screenshoty LogToola na jego stronie. Czy na którymkolwiek z tych trzech screenshotów widać w logu jakąś nieprawidłowość? Widzę jakieś kawałki źródła, jakieś zmienne, klamry. Jak to możliwe, że coś takiego widać? To efekt kprintf czy może się to "samo" robi?
Sorry za lamerstwo ale naprawdę tego nie używałem i pojęcia nie mam. :) Tak sobie patrzę na screenshoty LogToola na jego stronie. Czy na którymkolwiek z tych trzech screenshotów widać w logu jakąś nieprawidłowość? Widzę jakieś kawałki źródła, jakieś zmienne, klamry. Jak to możliwe, że coś takiego widać? To efekt kprintf czy może się to "samo" robi?
28.12.2007 10:59
[#13]
Re: Kontrolowana jazda po pamieci
@MDW, post #10
te klamerki to dodatek, jak odpowiednio skompilujesz kod, to po za zwyklą informacją o bledach, dostajesz fragment kodu twojego programu, ale tego nie probowalem nigdy, w starszych wersjach tego nie bylo... Na tym skrinshocie jest po prostu dodatkowa funkcjonalność pokazana. Pomiedzy te wszystkie informacje mozesz wlasnie powtykać kprintfy ze swojego programu - obsluga taka jak przy printf, tylko, że informacja ląduje po prostu w logu zamiast na konsoli. A co tam się znajdą za informacje - to już od ciebie zalezy.
28.12.2007 11:38
[#14]
Re: Kontrolowana jazda po pamieci
@Kaczus, post #13
Dzięki! Wystarczy mi, że kprintf wypisze mi w logu to co będę chciał i kiedy będę chciał. Tyle mi wystarczy żeby wyśledzić ewentualny problem. Rozumiem, że to na czerwonym tle to sa hity? Czy może na żółtym też? :)
A jeszcze taka sprawa techniczna... Podobno jak się ma min. 512MB RAM to log przeżywa reboot. To prawda? Ja mam tylko 256MB ale jak trzeba to skoczę do sklepu po jakąś kostkę 1GB. Nie ma problemu. Po prostu do tej pory nie potrzebowałem. :)
A jeszcze taka sprawa techniczna... Podobno jak się ma min. 512MB RAM to log przeżywa reboot. To prawda? Ja mam tylko 256MB ale jak trzeba to skoczę do sklepu po jakąś kostkę 1GB. Nie ma problemu. Po prostu do tej pory nie potrzebowałem. :)
28.12.2007 11:41
[#15]
Re: Kontrolowana jazda po pamieci
@Kaczus, post #5
Najlepszym sposobem na problemy z biblioteką standardową jest linkowanie z -nostdlib. Chociaż to czasem jest niewygodne, zwłaszcza przy portowaniu. Natomiast GCC 4 Morgotha polecam, pomijając szopki z AltiVecem, kod jest szybszy i krótszy w porównaniu do 2.95.3. Kompiluję czwórką dość spory projekt i nie mam z kompilatorem problemów.
28.12.2007 11:47
[#16]
Re: Kontrolowana jazda po pamieci
@MDW, post #6
Do tego wystarczy LogTool?
Nie. Nie wystarczy. Wyobraź sobie, że Twój program zapisuje bajt gdzieś w losowej lokacji. Jeżeli trafił akurat w pamięć wolną - fakt ten jest nie do wykrycia. Jeżeli uszkodzisz kod jakiejś aplikacji, to wywali się nie Twój program, a ta aplikacja i to nie od razu, a w momencie gdy ten kod zostanie wykonany (a to może być o wiele później). Jeżeli uszkodzisz jakieś struktury systemwe, to objawy mogą być tak dziwne, że nie będziesz w stanie tego sensownie powiązać. Tak niestety się dzieje w systemie bez ochrony pamięci.
Mogę sobie powtykać do programu jakieś takie debugowe printfy po którym będę mógł łatwiej zlokalizowac ewentualną przyczynę problemu? Jak uzyskać takie "wpisy"?
kprintf(), oraz -ldebug przy linkowaniu.
Nie. Nie wystarczy. Wyobraź sobie, że Twój program zapisuje bajt gdzieś w losowej lokacji. Jeżeli trafił akurat w pamięć wolną - fakt ten jest nie do wykrycia. Jeżeli uszkodzisz kod jakiejś aplikacji, to wywali się nie Twój program, a ta aplikacja i to nie od razu, a w momencie gdy ten kod zostanie wykonany (a to może być o wiele później). Jeżeli uszkodzisz jakieś struktury systemwe, to objawy mogą być tak dziwne, że nie będziesz w stanie tego sensownie powiązać. Tak niestety się dzieje w systemie bez ochrony pamięci.
Mogę sobie powtykać do programu jakieś takie debugowe printfy po którym będę mógł łatwiej zlokalizowac ewentualną przyczynę problemu? Jak uzyskać takie "wpisy"?
kprintf(), oraz -ldebug przy linkowaniu.
28.12.2007 12:01
[#18]
Re: Kontrolowana jazda po pamieci
@MDW, post #14
że to na czerwonym tle to sa hity? Czy może na żółtym też?
Zależy jak sobie pokolorujesz, to jest konfigurowalne... Na początku hitu masz jego rodzaj (najczęściej illegal read, illegal write albo program - błędny kod instrukcji proca). Potem zrzut rejestrów, licznik programu (SRR0), link register (trzyma adres powrotu z funkcji) i historię stosu. Reszta jest z reguły nieistotna. Adresy na stosie LogTool próbuje zdekodować podając nazwę modułu (programu/biblioteki) i offset. Dodatkowo LogTool 2.x potrafi załadować wskazane exe z debugiem (niezestripowane i skompilowane z -g) i wyświetlić nazwę funkcji i fragment kodu źródłowego odpowiadającego adresowi. Mi to nie zawsze działa, więc polegam na objdumpie, pisaniu krótkich funkcji i swojej znajomości asemblera PPC...
Podobno jak się ma min. 512MB RAM to log przeżywa reboot.
Podobno. Jednak jeżeli pracujesz serio to polecam podpięcie drugiego komputera przez kabel null-modem i przechwytywanie debugu na terminal (np. HyperTerminal pod Windows, albo drugi Pegasos i LogTool w trybie zgarniania z seriala). Ramdebug to tylko półśrodek.
Zależy jak sobie pokolorujesz, to jest konfigurowalne... Na początku hitu masz jego rodzaj (najczęściej illegal read, illegal write albo program - błędny kod instrukcji proca). Potem zrzut rejestrów, licznik programu (SRR0), link register (trzyma adres powrotu z funkcji) i historię stosu. Reszta jest z reguły nieistotna. Adresy na stosie LogTool próbuje zdekodować podając nazwę modułu (programu/biblioteki) i offset. Dodatkowo LogTool 2.x potrafi załadować wskazane exe z debugiem (niezestripowane i skompilowane z -g) i wyświetlić nazwę funkcji i fragment kodu źródłowego odpowiadającego adresowi. Mi to nie zawsze działa, więc polegam na objdumpie, pisaniu krótkich funkcji i swojej znajomości asemblera PPC...
Podobno jak się ma min. 512MB RAM to log przeżywa reboot.
Podobno. Jednak jeżeli pracujesz serio to polecam podpięcie drugiego komputera przez kabel null-modem i przechwytywanie debugu na terminal (np. HyperTerminal pod Windows, albo drugi Pegasos i LogTool w trybie zgarniania z seriala). Ramdebug to tylko półśrodek.