|
|
(Mateusz Wykurz)
(Robert Źrałek)
(Michał Przybyłek)
Literatura:
Jon Bentley "Perełki Oprogramowania", WNT 2001
Czyli ogólne metody odpluskwiania (lokalizowania błędu):
Kiedy zlokalizowanie błędu innymi metodami jest wystarczająco trudne, np.:
Literatura:
Jon Bentley "Perełki Oprogramowania", WNT 2001
Ian Sommerville "Inżynieria Oprogramowania", WNT 2003
Za pomocą debugera zwykle możemy:
Linki
Linki
|
|
Dla kogo VMware:
Zalety:
Wady:
2. UML (User Mode Linux)
User mode linux pozwala na odpalenie jądra linuxa pod uruchomionym jądrem w przestrzeni użytkownika (dlatego user mode). UML jest prostym i bezpiecznym sposobem na uruchomienie innych wersji linuxa i procesów linuxa pod istniejącym systemem bez ryzykowania uszkodzenia głównej konfiguracji sysemu.
W praktyce oznacza to ze tworzymy zupełnie wirtualna maszynę z możliwością posiadania większej ilości wirtualnego sprzętu i oprogramowania niż fizycznie znajduje się w komputerze. Wirtualnej maszynie można również udostępnić lub zabronić dostępu do dowolnego zasobu sprzętowego. Co teoretycznie zmniejsza zagrożenia uszkodzenia prawdziwego komputera.
UML nie emuluje całego komputera, działa za to jako kolejny proces użytkownika, co oczywiście wystarcza do zainstalowania dowolnego Linuksa. Jego podstawowe zastosowanie to możliwość stworzenia wirtualnej sieci, choć może także służyć jako system pomiarowy przepustowości sieci (potrafi obsługiwać wiele urządzeń sieciowych zainstalowanych na pojedynczym komputerze). Za pomocą UML można nawet stworzyć udostępniane wzajemnie przez wirtualne systemy udziały dyskowe.
Każda wirtualna maszyna dostarcza platformy, w której każdy nowy system operacyjny jest w stanie widzieć następujące urządzenia:
|
|
|
Jak to działa:
UML uruchamia swój scheduler niezależnie od scheduler-a głównego linuxa.
Scheduler głównego linuxa łatwo uzupełnia swoje struktury danych po wykonaniu jakichś czynności przez scheduler UML-a. W podobny sposób UML uruchamia swój własny wirtualny system. Alokuje niezbędną pamięć spośród istniejącej fizycznej przestrzeni adresowej głównego linuxa. Następnie mapuje przydzieloną pamięć na swoją wirtualną pamięć i określa tam swoją wirtualną przestrzeń adresową. Jeśli będzie istniała potrzeba konfiguracji pliku wymiany (swap) to zostanie podłączony plik wymiany.
Zasadniczo wszystko co w linuksie nie jest sprzętem lub nie odwołuje się do sprzętu w UML-u po prostu działa.
Normalnie jądro Linuxa odwołuje się bezpośrednio do sprzętu i każdy proces działający proces prosi jądro o odwołanie się do sprzętu.
+-----------+-----------+----+
| Process 1 | Process 2 | ...|
+-----------+-----------+----+
| Linux Kernel |
+----------------------------+
| Hardware |
+----------------------------+
Jądro UML pod tym względem różni się od zwykłego jądra. Jądro UML zamiast komunikować się z sprzętem komunikuje się z prawdziwym jądrem w celu komunikacji ze sprzętem tak jak zwykły program. Programy działające pod UML mogą normalnie uruchamiać tak jakby pracowały pod normalnym jądrem.
+----------------+
| Process 2 | ...|
+-----------+----------------+
| Process 1 | User-Mode Linux|
+----------------------------+
| Linux Kernel |
+----------------------------+
| Hardware |
+----------------------------+
UML ułatwia też pracę programistom, którzy mogą przetestować swoje dzieło w wielu środowiskach linuksowych. Kolejne zastosowanie wiąże się z wymogami bezpieczeństwa. Jeśli nie zależy nam na wydajności serwera lub dysponujemy wydajną sprzętowo maszyną, możemy pokusić się o instalację serwera WWW lub pocztowego pod kontrolą UML. Przy takiej konfiguracji włamanie się z zewnątrz będzie miało wpływ tylko na system pracujący pod kontrolą UML. Bezpieczeństwo całej sieci czy farmy serwerów pozostanie zaś nienaruszone.
Kompilacja UML przypomina pod każdym względem kompilację zwykłego jądra linuksowego.
Konfigurację jądra, przed kompilację przeprowadzamy tak samo jak dla zwykłego jądra, specyfikując jawnie architekturę jako um (domyślną architekturą będzie i386, dla maszyn PC).
make ARCH=um menuconfig
O ile UML był programem, uruchamianym ze zwykłego Linuxa, o tyle XEN jest samodzielnym quasi-systemem. Wymaga samodzielnego bootowania. W nagrodę dostajemy bardzo wydajny system, o prędkości niemal nie ustępującej pracy systemu natywnego na prawdziwym sprzęcie.
Kompilacja jądra linuksowego na platformę XEN, przebiega podobnie jak ta na platform_ UML.
make ARCH=xeno menuconfig
make ARCH=xeno bzImage
Niemniej, samo jądro tutaj nie wystarczy. Potrzebna jest instalacja samego
XEN-a. W przypadku loadera GRUB, który jest standardowy w większości
dystrybucji linuksowych, wystarczy stworzyć następujący wpis
title Xen / XenoLinux 2.4.22
kernel /boot/xen.gz dom0_mem=131072 ser_baud=115200 noht
module /boot/xenolinux.gz root=/dev/hda2 ro console=tty0
gdzie xen.gz jest samym XEN-em, a xenolinux, jądrem Linuxa, skompilowanym dla XEN-a. Pierwszy Linux pracuje w domenie-0, i jest przywilejowany. Tylko jeden Linux może pracować w tej domenie. Kolejne mogą być uruchamiane odpowiednimi narzędziami.
Testy:
Native Linux (L)
Xen/Linux (X)
VMware Workstation 3.2 (V)
User Mode Linux (U)
|
Cecha |
VMware |
UML |
XEN |
|
Instalacja wymaga modyfikacja |
|
TAK |
TAK |
|
Instalacja wymaga modyfikacji partycji |
NIE |
NIE |
Wymaga modyfikacji wpisów w bootloaderze |
|
Wymaga dostosowania systemu do współpracy |
NIE |
TAK |
TAK |
|
Możliwość łańcuszków systemów |
Dowolny system w dowolnym |
Możliwość uruchamiania nowego UMLa w już uruchomionym |
Raczej nie |
|
Szybkość działania |
Średnia |
Duża |
Bardzo dużą |
|
Odpłatność |
Rozwiązanie komercyjne |
Darmowe |
Darmowe |
Zestaw narzędzi do debuggowania pod Windows (Debugging Tools):
Odpluskwianie z użyciem WinDbg
WinDbd używa do debuggowania zestawu symboli w formacie używanym przez Microsoft Visual Studio. Może uzyskać dostęp do dowolnej funkcji i zmiennej wyeksportowanej przez kompilator przy kompilowaniu modułów. Eksportowane zmienne zazwyczaj umieszczane są w plikach (.pdb)
Przykład z pliku .pdb (pliki .pdb są plikami binarnymi):
RobRenderMany_3ds@MyLoader@vector@RenderInfo@$allocator@RenderInfo
WinDbg potrafi wyświetlać kod źródłowy aplikacji. Potrafi ustawiać breakpoints, wyświetlać zmienne, obiekty C++ oraz struktury. Istnieje możliwość śledzenia stosu, pamięci i kodu (również po assemblerowego) podczas debuggowania. Zawiera również linie komend w celu wywołania komend, których wywołanie za pomocą graficznego interfacu jest niemożliwe.
WinDbg zazwyczaj wymaga dwóch komputerów (maszyny hosta i maszyny docelowej) w celu debuggowania w trybie jądra. Umożliwia również zdalne odpluskwianie kodu w trybie użytkownika.
Porównanie narzędzi do obpluskwiania pod Windows:
|
Cecha |
KD |
NTSD |
WinDbg |
Visual Studio .NET |
|
Kernel-mode debugging |
Y |
N |
Y |
N |
|
User-mode debugging |
|
Y |
Y |
Y |
|
Unmanaged debugging |
Y |
Y |
Y |
Y |
|
Managed debugging |
|
Y |
Y |
Y |
|
Remote debugging |
Y |
Y |
Y |
Y |
|
Attach to process |
Y |
Y |
Y |
Y |
|
Detach from process in Win2K and XP |
Y |
Y |
Y |
Y |
|
SQL debugging |
N |
N |
N |
Y |
Przykład:
CPU: 0
EIP: 0010:<c011933c> Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00000ce0 ebx: 00001000 ecx: c778a510 edx: 00000610
esi: 00000002 edi: 00000000 ebp: c02165c0 esp: c6663f58
ds: 0018 es: 0018 ss: 0018
Process pcmcia (pid: 1003, stackpage=c6663000)
Stack: 00000000 c02165a0 00000000 c02165c0 c6663fc4 c01193cf c010ac96 c0116406
c0116340 00000000 00000001 c02165c0 fffffffe c011616a c02165c0 00000000
c0214900 00000000 c6663fbc 00000046 c010817d 00000000 080caa18 00000000
Call Trace: <c01193cf><c010ac96><c0116406><c0116340><c011616a><c010817d><c0109f48>
Code: 89 42 04 89 10 c7 41 04 00 00 00 00 c7 01 00 00 00 00 fb 53
Przykład z działanie ksymoops:
EIP; c0113f8c <sys_init_module+49c/4d0>
Trace; c011d3f5 <sys_mremap+295/370>
Trace; c011af5f <do_generic_file_read+5bf/5f0>
Trace; c011afe9 <file_read_actor+59/60>
Trace; c011d2bc <sys_mremap+15c/370>
Trace; c010e80f <do_sigaltstack+ff/1a0>
Trace; c0107c39 <overflow+9/c>
Trace; c0107b30 <tracesys+1c/23>
KGBD jest odpluskwiaczem na poziomie źródeł jądra linuxa. KGDB wraz z gdb służy do odpluskwiania jądra.
Odpluskwianie jądra z użyciem KGDB niczym nie różni się od odpluskwiania zwykłej aplikacji. Możliwe jest stosowanie place breakpointów w źródłach jądra. Dowolne chodzenie po kodzie i obserwowanie zmiennych.
Do działania KGDB potrzebuje dwóch komputerów. Maszyna testowana z maszyną testującą jest połączona kablem szeregowym. Na maszynie testowej jest uruchomiony KGDB a na maszynie testującej GDB. Połączenie szeregowe jest wykorzystywane do prze gdb do komunikacji z testowanym jądrem.
I. Inny świat
"Way back in the good old days -
when men were men,
women were women,
and hackers were indeterminate -
if you were doing AI, you were doing LISP…"
- Chris Welty
1. Czynniki determinujące niezawodność aplikacji
3. Degres technologiczny lat '80 - od Lispu do Uniksa i C (Speedability beats Reliability)
Richard Gabriel 1989 (za profesorem Edgarem Dijkstrą)
4. Powrót do idei z czasów Lispu (Reliability beats Speedability)
Microsoft i Singularity - jak by wyglądał system stworzony całkowicie od nowa z myślą o niezawodności ?
Sun i JX - model bazujący na "dziedzinach" i "portalach"
3. Profilery w Eclipse i NetBeans
