Max Hansen max.hansen@wp.pl Energy, Oil and Gas Industry Congo, Angola and Singapore Andrzej Rychlik Politechnika Radomska, Instytut Informatyczno-Techniczny Politechnika Łódzka, Instytut Informatyki Tworzenie aplikacji dla systemu operacyjnego QNX Neutrino Zintegrowane środowisko programistyczne (ang. Integrated Development Environment) to oprogramowanie udostępniające zestaw narzędzi i bibliotek służących do tworzenia, modyfikowania, testowania i konserwacji oprogramowania. W systemie QNX najpopularniejszym środowiskiem programistycznym jest Momentics IDE oparte o platformę Eclipse, działające w całości na Javie, a udostępniające programiście, m.in. możliwość kompilacji kodu pod wybrany procesor. Celem rozdziału jest przedstawienie procesu wytwarzania oprogramowania dla systemu QNX Neutrino, poczynając od prezentacji popularnych kompilatorów, a skupiając się głównie na tematyce wytwarzania w środowisku QNX Momentics IDE. Wprowadzenie do programowania dla QNX Neutrino Środowisk programistycznych dla systemu QNX jest wiele, jednak największą popularnością cieszy się zaledwie garstka. Najpopularniejszy multiplatformowy kompilator to CC i GCC wbudowany w system. Bardzo popularnym środowiskiem wykorzystującym GCC jest GNAT. Posiada on rozbudowany system testów ACATS, zaś źródłem dobrych przykładów na wykorzystanie w praktyce tego kompilatora może być strona http://www.ajam.org.pl/ programy/ gnat-examples.tar.bz2. Generalnie w systemie QNX praktycznie każde środowisko programistyczne oparte jest o kompilator GCC, który w zależności od parametrów potrafi obsługiwać różne języki programowania, poziomy optymalizacji, itp. QNX Neutrino i QNX Momentics IDE QNX to system czasu rzeczywistego, którego priorytetem jest bezpieczeństwo, w tym gwarancja wykonywania operacji w określonych ramach czasowych. W związku z tym istnieją odpowiednie zasady tworzenia oprogramowania dla tego systemu. Elementom tworzonego oprogramowania przypisuje się odpowiednie priorytety wykonywania, wedle których system będzie miał prawo na dopuszczanie opóźnień danego elementu, bądź tego prawa nie otrzyma. Dwa niezbędne składniki QNX Neutrino, traktowane łącznie jako jądro, objęte jedną nazwą pronto, to: mikrojądro systemu, będące modułem programowym dostarczającym elementarnych usług umożliwiających działanie procesów; 1
administrator procesów, czyli proces zarządzający pamięcią, przestrzenią nazw plików, czy procesami w systemie. Aby programować pronto niezbędna jest odpowiednia platforma programistyczna. Najlepszym rozwiązaniem na rynku cieszącym się coraz większą popularnością jest QNX Momentics. QNX Momentics zawiera w pakiecie system operacyjny QNX Neutrino, środowisko graficzne Photon, wraz z oprogramowaniem do tworzenia aplikacji okienkowych phab, środowisko programistyczne IDE, narzędzia do pisania sterowników DDK, pakiety BSP, biblioteki i narzędzia GNU, instruktarzowe klipy wideo, obszerną dokumentację oraz szereg kodów. Pakiety BSP (Board Support Package) są zestawem narzędzi do uruchamiania systemu operacyjnego wraz z kompletną obsługą urządzeń docelowej platformy sprzętowej. Liczba zestawów wciąż rośnie, a dostępne są pod adresem: http://www.qnx.com/products/ ps_bsps. Przykładowy skrócony harmonogram tworzenia w QNX Momentics IDE oprogramowania dedykowanego: Utworzenie projektu i zaimportowanie do niego pakietów BSP File > Import ; Opisanie kodem i konfiguracja na bazie BSP; Budowanie projektu przez make all zawarty w BSP; W rezultacie mamy bootowalny obraz systemu operacyjnego! Rys. 1. QNX Momentics IDE: Import pakietów źródłowych i BSP, krok 1 2
Wybieramy repozytorium źródeł BSP. Rys. 2. QNX Momentics IDE: Import pakietów źródłowych i BSP, krok 2 Zaznaczamy interesującą nas wersję pakietów BPS. Rys. 3. QNX Momentics IDE: Import pakietów źródłowych i BSP, krok 3. Wybieramy architekturę na jaką ma być zaimportowany BSP 3
Ustawienia projektu, w tym katalog docelowy, prefix. Rys. 4. QNX Momentics IDE: Import pakietów źródłowych i BSP, krok 4 Instalacja QNX Software Development Platform Do pracy nad projektem dla systemu QNX niezbędne jest odpowiednie środowisko programistyczne, jak QNX Software Development Platform. Ściągamy oprogramowanie ze strony http://www.qnx.com/download/feature.html?programid=21180, na której także wypełniamy formularz rejestracyjny. Otrzymamy na podany przez nas w formularzu adres email, podziękowania za ściągnięcie testowej wersji platformy deweloperskiej QNX oraz w chwilę później klucz licencyjny potrzebny do aktywacji testowej wersji oprogramowania. QNX Software Development Platform oferuje wersje dla różnych systemów operacyjnych jak Windows, Solaris, Linux, czy QNX Neutrino. Na potrzeby prezentacyjne wybieramy wersję oprogramowania pod Windows, zaczynając instalację od zatwierdzenia harmonogramu instalacyjnego QNX SDP. (Możliwość tworzenia oprogramowania w QNX SDP dla jądra QNX Neutrino w systemach Windows, Solaris, czy Linux umożliwia zmniejszenie kosztów wdrożenia narzędzi deweloperskich w firmach pracujących trwale w środowiskach Windows/Linux) 4
Rys. 5. Instalacja QNX SDP rozpoczęcie instalacji Kolejnym krokiem jest wprowadzenie klucza produktu, który otrzymaliśmy po rejestracji na podany w formularzu adres email. Rys. 6. Instalacja QNX SDP wprowadzanie klucza produktu Aby kontynuować należy także zaakceptować warunki licencji. Rys. 7. Instalacja QNX SDP akceptacja warunków licencji 5
Wybieramy ścieżkę, w której ma być zainstalowane oprogramowanie. Rys. 8. Instalacja QNX SDP wybór ścieżki instalacji Zaznaczamy opcjonalne elementy produktu. Rys. 9. Instalacja QNX SDP wybór opcjonalnych elementów Wyświetlone zostaje podsumowanie wybranych opcji do zatwierdzenia. Rys. 10. Instalacja QNX SDP zatwierdzenie podsumowania 6
Rozpoczyna się proces instalacji. Rys. 11. Instalacja QNX SDP proces ładowania środowiska Po instalacji otrzymujemy informację o lokalizacji przewodnika licencyjnego, po zatwierdzeniu, którego możemy rozpocząć pracę nad projektem. Rys. 12. Instalacja QNX SDP informacja o pozytywnym ukończeniu instalacji Rys. 13. Instalacja QNX SDP informacja o lokalizacji przewodnika licencyjnego Pierwsze uruchomienie QNX Momentics IDE 4.7 Przy pierwszym uruchomieniu QNX Momentics IDE ukazuje nam się zakładka Welcome dostępna przy późniejszych próbach odsłony pod menu Help > Welcom. 7
Rys. 14. Instalacja QNX SDP Powitanie Zakładka oferuje bezpośredni dostęp do dokumentacji środowiska i języków programowania, wprowadzenie do środowiska, kursy, przykładowe małe projekty wdrożeniowe programisty oraz bezpośrednie przekierowanie do właściwej części środowiska, celem rozpoczęcia pracy nad projektem (tzw. Workbench). Rys. 15. Instalacja QNX SDP Workbench starter Po kliknięciu opcji Workbench uruchomiona zostaje część właściwa środowiska. 8
Rys. 16. Instalacja QNX SDP Workbench Tworzenie projektu w QNX Momentics IDE 4.7 Aby utworzyć nowy projekt C++, wybieramy File > New > QNX C++ Project z głównego menu. Rys. 17. QNX SDP Tworzenie projektu, krok 1 Nadajemy jakąś nazwę projektowi (np. MyFirstProject ). 9
Rys. 18. QNX SDP Tworzenie projektu, krok 2 W następnym kroku wybieramy architekturę procesora (zakładka Build Variants), na którą będziemy tworzyć oprogramowanie (w naszym przypadku x86), klikając przycisk "Finish celem utworzenia szkieletu projektu. Rys. 19. QNX SDP Tworzenie projektu, krok 3 Naszym oczom ukaże się prosty przykładowy kod, realizujący wyświetlenie na ekranie powitania w środowisku QNX Momentics IDE. #include <cstdlib> #include <iostream> int main(int argc, char *argv[ ]) { std::cout << "Welcome to the QNX Momentics IDE" << std::endl; return EXIT_SUCCESS; Kompilacja, konsolidacja, uruchamianie w QNX Momentics IDE 4.7 Celem utworzenia plików wykonywalnych prawym przyciskiem myszy klikamy na nazwie projektu wybierając Build Project. W konsoli wyświetlone zostaną opcje z jakimi program został skompilowany i/lub ewentualne błędy kompilacji. 10
Rys. 20. QNX SDP Logi procesów tworzenia Uruchamianie programu konfigurujemy po wyborze opcji Run > Run As > C/C++ QNX application ustanawiając, m.in. argumenty uruchomieniowe, wirtualne środowisko w jakim projekt ma być uruchamiany, priorytet czy sposób kolejkowania. Rys. 21. QNX SDP Konfiguracja uruchomieniowa projektu Po uzupełnieniu pól przede wszystkim w karcie Main, możemy uruchomić aplikację, czego rezultat obejrzymy w podglądzie konsoli. Tworzenie oprogramowania dla urządzeń wbudowanych QNX Momentics wspiera 3 nurty tworzenia oprogramowania: self-hosted development Oprogramowanie tworzy się i uruchamia na tym samym komputerze. cross-development Przygotowuje się oprogramowanie dla maszyny docelowej target innego typu niż maszyna deweloperska host. Główną i chyba najistotniejszą różnicą jest typ procesora w obu komputerach. host-target development Oprogramowanie tworzy się na stacji zwanej hostem, a uruchamia na maszynie docelowej zwanej targetem. Metodą tą tworzy się oprogramowanie dla systemów wbudowanych, by uniknąć problemów związanych z różnicą architektury hosta i targetu. 11
Przykładowe problemy związane z różnicami architekturalnymi systemu hosta i systemu docelowego: za małe zasoby pamięciowe, procesorowe; brak, bądź zbyt ubogi interface; niewystarczające zasoby osprzętowe; brak wsparcia dla danych rozdzielczości. Celem uzyskania dostępu do systemu docelowego z IDE, należy utworzyć projekt docelowy ( Target Project ), przez otwarcie perspektywy informacji systemowej: w menu okna Open Perspective > Other > QNX System Information. W pustym oknie Target Navigator klikamy prawym przyciskiem myszy, po czym wybieramy Ad New Target. Wprowadzamy następnie nazwę systemu docelowego oraz jego adres IP. Jeśli docelowym systemem jest QNX Neutrino w konsoli ukaże się lista procesów uruchomionych w tymże systemie. Obsługa wątków W systemie QNX obsługa wątków realizowana jest przez mikrojądro. System zapewnia wszystkie procedury obsługi i synchronizacji wątków, dostarcza standardowego interfejsu wątków POSIX 1003.1. Tworzenie wątków w programach Neutrino jest bardzo proste. Wystarczy dołączyć bibliotekę pthread.h do nagłówka programu C/C++ i wykorzystać funkcje pthread_*(). Dołączanie nagłówka celem korzystania z wątków POSIX: #include <pthread.h>... Przy kompilacji (dokładniej przy konsolidacji) należy dołączyć bibliotekę libc. Przykładowo, żeby skompilować program a.c należy wpisać: $ qcc a.c -l c Wszystkie funkcje oraz typy danych tworzące API wątków POSIX owych mają nazwy rozpoczynające się od przedrostka pthread_. Wątki obiektowo Wątkowość bardzo słabo nadaje się do implementacji obiektowej. Wątki tworzone i wysyłane są w blokach kodowych, po czym dostarczane z wywołań zwrotnych funkcji do wykonywanych zadań. Taka kolej rzeczy wpływa na to, że programista sięga do zmiennych globalnych, powstają segmenty, całkowicie słabego jakościowo kodu. Tradycyjnie tworzenie i wysyłanie wątku wygląda mniej więcej tak: void * callback_function(void *object) { // Wykonywanie jakiegoś kodu int main(int argc, char **argv) {... int threadid; threadid = ThreadCreate(0, &callback_function, NULL, NULL); 12
... ThreadCreate jest funkcją, która tworzy i wysyła wątek. #include <sys/neutrino.h> int ThreadCreate( pid_t pid, void* (func)( void* ), void* arg, const struct _thread_attr* attr ); pid: tu używamy ID procesu, którym chcemy utworzyć wątek lub 0 by utworzyć wątek w aktualnym procesie. Przykład uproszczonego programu opartego o wątki: #include <pthread.h> //--------------------------------------------------------- void * functhreada( void ) { int a_petla; for ( a_petla = 1; a_petla <= 20; a_petla++ ) { printf( "A\n" ); sleep( 1 ); // opoznienie return; //--------------------------------------------------------- void * functhreadb( void ) { int b_petla; for ( b_petla = 1; b_petla <= 10; b_petla++ ) { printf( "B\n" ); sleep( 2 ); return; //----------------------------------------------------------- int main( void ) { pthread_t threada; 13
pthread_t threadb; printf( "Startowanie glownego programu\n" ); /* Tworz watek, dodaj do istniejacego, pthread_create( &threada, NULL, &functhreada, NULL ); pthread_create( &threadb, NULL, &functhreadb, NULL ); printf( "Glowny program oczekuje..\n" ); pthread_join( threada, NULL ); pthread_join( threadb, NULL ); printf( "Glowny program konczy\n" ); return 0; Istnieje możliwość na znalezienie prostego rozwiązania obiektowego tworzenia wątku. class SomeClass { public: SomeClass() { ThreadCreate(0, &SomeClass::someMethod, NULL, NULL); private: int somevariable; static void *somemethod(void *object) { SomeClass *classinstance = dynamic_cast<someclass*>(object); if (!classinstance) return NULL; while (!done) { if (somethingchanged) classinstance->somevariable++; ; Administracja procesami Procesy są podstawowymi składnikami budulcowymi każdej aplikacji systemów wielozadaniowych. W systemie QNX istnieje kilka metod tworzenia procesów. Metody tworzące procesy w systemie QNX to: fork() tworzy proces potomny procesu macierzystego w formie kopii; exec*() zastąpienie bieżącego procesu procesem utworzonym z podanego jako parametr funkcji pliku wykonywalnego; spawn*() dają efekt wywołania sekwencji funkcji fork() i exec*(); system() najprostsza metoda utworzenia procesu. Na zakończenie procesu powinny składać się następujące czynności: zakończenie komunikacji z innymi procesami; 14
zwolnienie zasobów zajmowanych przez proces; oczekiwanie na zakończenie procesów potomnych. Metody kończące procesy w systemie QNX to: exit() powoduje zakończenie bieżącego procesu; wait(), waitpid() wykorzystywane do synchronizacji zakończenia procesu; spawn*() dają efekt wywołania sekwencji funkcji fork() i exec*(); system() najprostsza metoda utworzenia procesu. Do kontroli procesów w systemie QNX wprowadzono odpowiednie limity, które można określać metodą setrlimit(), zaś testować metodą getrlimit(). Tab. 1. Zasoby systemowe podlegające ograniczeniu Oznaczenie Opis Akcja przy przekroczeniu RLIMIT_CORE Pamięć operacyjna Zakończenie procesu RLIMIT_CPU Czas procesora Wysłanie sygnału SIGCPU do procesu przekraczającego zasób RLIMIT_DATA Wielkość pamięci pobranej ze sterty Funkcja pobierająca pamięć kończy się błędem RLIMIT_FSIZE Max plik tworzony przez proces Wysłanie sygnału SIGXFSZ do procesu przekraczającego zasób Max liczba deskryptorów plików Funkcja tworząca ponad limitowe pliki RLIMIT_NOFILE tworzonych przez proces zakończy się błędem ELIMIT_STACK Maksymalny rozmiar stosu Wysłanie sygnału SIGSEGV do procesu przekraczającego stos RLMIT_NPROC Maksymalna liczba procesów Procesy potomne przekraczające limit potomnych tworzonych przez proces nie będą tworzone Celem kontrolowania danych procesów należy posługiwać się odpowiednimi atrybutami procesów. 15
Tab. 2. Atrybuty procesów w systemie QNX Atrybut procesu Testowanie Ustawianie Identyfikator procesu PID getpid() Identyfikator procesu macierzystego PPID getppid() Numer grupy procesów PGID getpgrp() setpgrp(), setpgid() Identyfikator sesji SID getsid() setsid() Rzeczywisty identyfikator użytkownika UID getuid() Rzeczywisty identyfikator grupy GID getgid() Środowisko procesu getenv() putenv() Katalog bieżący getcwd() chdir() Priorytet procesu getprio(), setprio(), sched_getparam() sched_setparam() Strategia szeregowania sched_getparam() sched_setparam() Zarządzanie procesami wiąże się z następującymi czynnościami: testowaniem i ustawianiem atrybutów procesu; tworzeniem i kończeniem procesu; synchronizacją zakończenia procesu potomnego z jego procesem macierzystym; testowaniem statusu zakończonego procesu potomnego. W systemach wielozadaniowych prawie zawsze istnieje pewien podzbiór procesów oddziaływującym na siebie. Źle zorganizowany dostęp do tych samych zasobów prowadzi do wielu problematycznych sytuacji. W systemach opartych o priorytety z możliwością wywłaszczania (w tym QNX), projektanci muszą wykazywać się szczególną ostrożnością. Najczęściej powstającym złym scenariuszem jest tworzenie procesów o wysokich priorytetach, przekazujących między sobą zasoby, a nie dopuszczających pozostałych procesów. Takie sytuacje doprowadzają do niemożliwości zakończenia zadań mniej priorytetowych, aczkolwiek nadal ważnych, nazywa się to głodzeniem, bądź wykluczeniem. Innym jeszcze gorszym problemem są zakleszczenia procesów lub inwersja priorytetów. Zakleszczenie procesów to sytuacja, w której dane procesy nawzajem blokują sobie wzajemnie zasoby systemowe. Przykładowo, istnieją w systemie 3 procesy, nazwijmy je P1, P2, P3 oraz docelowe zasoby zwane Z1, Z2, Z3. Proces P1 posiada Z1, lecz potrzebuje do działania również dostępu do Z2, zaś P2 nie może być wykonane, ponieważ potrzebuje dostępu do Z3, do tego jeśli P3 potrzebuje dostępu do Z1, zarezerwowanego przez P1 system potrzebuje jakichś określonych metod wykrywania sytuacji i limitów czasowych na jej blokowanie (algorytmy wykrywające zakleszczenie procesów opierają się o teorię grafów). Inwersja priorytetów polega na tym, że zadanie o niskim priorytecie zajmując zasób dzielony, zmusza zadanie o wyższym priorytecie do przejścia w stan blokowane i oczekiwania na zwolnienie tego zasobu. Taka sytuacja prowadzi do wielu 16
niebezpieczeństw, które w najgorszym wypadku mogą powodować powstanie sporych anomalii czasowych w systemie. System operacyjny QNX posiada sprawne systemy zarządzania procesami współbieżnymi, tj. nadawanie procesom priorytetów, wywłaszczanie procesów mniej priorytetowych, kolejkowanie procesów, zoptymalizowane czasowo przełączanie procesów. W systemie QNX priorytety, to liczby całkowite z zakresu 0-31 dla zadań super użytkownika lub 0-19 dla pozostałych. Wątki dziedziczą priorytet od swoich zadań macierzystych. Najniższy priorytet działa w tak zwanym tle (ang. idle), a jego wątki realizowane są wtedy, gdy w systemie nie ma nic innego do roboty. Zadanie idle jest zawsze gotowe do wykonania (ang. ready to run). Zadania uruchomione przez powłokę standardowo uzyskują priorytet 10. Każde zadanie, w oparciu o swój priorytet, trafia do odpowiedniej kolejki, tzw. FIFO (ang. First In First Out), działając wedle zasady pierwszy przyszedł, pierwszy zostanie obsłużony. System QNX dostarcza trzy algorytmy szeregowania procesów, które są używane, gdy istnieją równoważne priorytetowo zadania ubiegające się o procesor: Kolejka FIFO. Zadanie wybrane do wykonywania, kontynuuje swoje działania, aż samo odda sterowanie, np. procesowi systemowemu, zostanie wywłaszczone przez zadanie o wyższym priorytecie, bądź trwa do zakończenia. Algorytm karuzelowy, oparty o kolejkę FIFO, lecz z limitem czasowym, który wynosi 50 ms. Wówczas zadanie zostaje wywłaszczone, poza warunkami opisanymi we wcześniejszym algorytmie, również wtedy, kiedy wykorzysta przydzielony mu czas. Algorytm adaptacyjny (ang. adaptive scheduling), podobnie jak karuzelowy ograniczony kwantem czasu, lecz jeśli dane zadanie wykorzysta przydzielony czas procesora i nie zostanie zablokowane, to jego priorytet jest dekrementowany o jeden poziom, po czym po przebiegu każdej kolejnej sekundy oczekiwania na wykonanie podnoszony o jeden, lecz nie wyżej niż do stanu początkowego. Algorytm ten znajduje zastosowanie w sytuacjach, kiedy zadania wykonujące ogromne ilości obliczeń dzielą czas procesora z zadaniami interaktywnymi. Jest to domyślny algorytm dla programów uruchamianych przez powłokę. Algorytm szeregowania może być przyporządkowywany do zadania w sposób dynamiczny. Wybór konkretnego algorytmu szeregowania może być dokonywany przy pomocy funkcji POSIX takich jak: sched_getscheduler(), sched_set_scheduler(). Reasumując, podczas projektowania aplikacji działających w oparciu o priorytety należy trzymać się zasad bardzo starannego zarządzania zasobami, bowiem nawet te najlepsze metody zabezpieczeń systemowych niosą za sobą ryzyko krytycznych opóźnień systemu, utraty danych, bądź innych niekorzystnych sytuacji. Zadania powinny działać według określonych zasad: procesy zwalniają zasoby możliwie najszybciej; hierarchiczna organizacja zasobów; implementacja protokołu przydziału. 17
Błędy a QNX Neutrino Odnajdywanie błędów Ponieważ każdy program posiada błędy, nigdy nie ma pewności czy i kiedy otrzymamy zapytanie od użytkownika stworzonej przez nas aplikacji dlaczego po kilku dniach użytkowania program przestaje działać. Jeśli tak się stanie może to oznaczać, że nasz program generuje błędy, gdzieś w pamięci. Debugowanie błędów pamięciowych potrafi być irytujące, jednak na nasz ratunek przychodzi perspektywa analizy pamięci QNX. Ułatwieniem dla tejże perspektywy jest modułowa budowa systemu Neutrino, izolująca problematyczne procesy w systemie. Perspektywa analizy pamięci QNX pokazuje jak nasz program wykorzystuje pamięć pomagając upewnić się, że nie wywołuje problemów. Perspektywa ta pomaga szybko wskazać błędy pamięciowe naszego środowiska testowego przed tym jak nasz klient otrzyma produkt. Należy pamiętać jednak, iż perspektywa analizy pamięci potrafi dawać nieoczekiwane rezultaty, kiedy więcej niż jedno IDE komunikuje się z systemem docelowym. Tak więc do używania omawianej perspektywy należy zawsze mieć pewność, iż tylko jedno IDE jest podłączone pod system docelowy. Wycieki pamięciowe Wycieki pamięciowe polegają na nadmiernym zużywaniu pamięci przez aplikację, bądź próbie zapisu danych w niedozwolonym obszarze. Działania takie mogą być spowodowane przez alokację pamięci, która nie jest wolna, referencję na zły obszar pamięci, bądź nie zwalnianie pamięci przez programistę. Typową reakcją zabezpieczeń systemu przy wycieku aplikacji jest błąd krytyczny w momencie, gdy system identyfikuje próbę zapisu w chronionym obszarze. Nie ma jednak zabezpieczeń przed sytuacjami, gdzie programista nie zwalnia zarezerwowanej wcześniej pamięci. W takiej sytuacji, jeśli rezerwacja wywoływana jest na zasadzie aktualnych potrzeb automatycznie może dojść do sytuacji niekontrolowanego rozrastania się aplikacji w przestrzeni pamięciowej. (Sytuacje takie wyklucza Java, która zaopatrzona jest w tzw. garbage collection, działający na zasadzie regularnego sprawdzania i usuwania z pamięci niepotrzebnych elementów. Jednak języki programowania systemów specjalistycznych jak C/C++ wymuszają na programiście konieczność przykładania dodatkowej uwagi, co swoją drogą ma dobre strony pod kątem oszczędności zasobów. QNX Neutrino tropi zachowanie każdego programu oraz zarezerwowaną przez niego pamięć, więc kiedy nastąpi zawieszenie programu system przywróci całą pamięć przez niego zarezerwowaną, włączając tą utraconą przez wycieki. Jeśli nasz program ma poważny wyciek, bądź wyciek powolny, ale niezawieszający programu, może to prowadzić nawet do błędów głównych serwisów systemu. Następujące elementy edytora analizy pamięci mogą pomóc odnaleźć błędy i uporać się z nimi: Allocation tabs: pokazuje wszystkie instancje, w których nasz program alokuje, realokuje czy też zwalnia pamięć, co pozwala określić, które elementy zostały niepotrzebnie zarezerwowane w zły sposób. 18
Errors tabs: pokazuje wszystkie błędy pamięciowe, wliczając w to wycieki. Aby uruchomić program z analizą pamięci, należy we właściwościach aplikacji wybrać typ uruchamiania lub debbugowania, po czym odszukać opcje memory analisys. Literatura http://www.qnx.com/developers/docs/6.3.0sp3/neutrino/ [dostęp [dostęp 22.05.2011] http://www.qnx.com/developers/docs/6.3.2/momentics/quickstart/about.html [dostęp 20.05.2011] http://www.qnx.com/developers/docs/6.3.2/photon/prog_guide/about.html [dostęp 23.05.2011] http://www.qnx.com/developers/docs/6.3.0sp3/ide_en/user_guide/concepts.html [dostęp 23.05.2011] http://psy.swan.ac.uk/staff/carter/qnx/tut_nto_thread_ab.htm [dostęp 10.06.2011] http://www.eetimes.com/design/embedded [dostęp 10.06.2011] http://www.se.rit.edu/~rtembed/qnx-tutorials/guides/oothreads-tutorial.pdf [dostęp 20.05.2011] Hansen M., Rychlik A.: Przeglad systemów operacyjnych w systemach bezpieczenstwa. [W:] Informatyka w dobie XXI wieku. Nauka, technika, edukacja a nowoczesne technologie informatyczne. Pod red. Aleksandra Jastriebowa i Marii Raczynskiej. Radom 2011 19