Studie en implementatie van input replay door Frank Cornelis

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: Prof. dr. ir. J. Van Campenhout Studie en implementatie van input replay door Frank Cornelis Promotor: Prof. K. De Bosschere Scriptiebegeleider: Michiel Ronsse Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica, optie software-ontwikkeling Academiejaar

2

3 Voorwoord Graag wil ik een woord van dank richten aan ieder die heeft bijgedragen tot de realisatie van deze scriptie. Allereerst dank ik prof. K. De Bosschere voor het zeer boeiende onderwerp en voor de wetenschappelijke ondersteuning. Mijn speciale dank gaat uit naar M. Ronsse, dit voor het mogen inkijken van zijn experimentele code, de intense begeleiding en de leerrijke tussentijdse vergaderingen. Ook diegene die me via de linux-kernel mailing list geholpen hebben, door steeds mijn vragen te behandelen, ben ik zeer erkentelijk. Tevens wens ik alle professoren te danken voor de theoretische en praktische kennis die ze mij gedurende mijn informaticastudie hebben bijgebracht. Tenslotte bedank ik mijn ouders omwille van de geboden kans en hun aanmoedigingen om deze studie tot een goed eind te brengen. Frank Cornelis 29 mei 2002 i

4 VOORWOORD ii Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Frank Cornelis 29 mei 2002

5 Studie en implementatie van input replay door Frank Cornelis Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica, optie software-ontwikkeling Academiejaar Promotor: Prof. K. De Bosschere Scriptiebegeleider: Michiel Ronsse Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Elektronica en Informatiesystemen Voorzitter: Prof. dr. ir. J. Van Campenhout Samenvatting Bij input replay wordt in een eerste fase de invoer van een bepaald programma vastgelegd in een bestand. Dit bestand kan later gebruikt worden in een replay-fase als invoer voor dit programma. Hiertoe wordt de normale invoer van het programma geblokkeerd en wordt de invoer, die in de record-fase werd opgeslaan, in het programma geïnjecteerd. Wel is het soms gewenst om zelfs in de replay-fase bepaalde systeemoproepen, zowel voor invoer als voor uitvoer, ook effectief te laten plaatsvinden. Een voorbeeld hiervan betreft het wegschrijven naar het scherm; in replay-fase wensen we ook de schermuitvoer van het programma te bekijken. De implementatie van deze input replay werd uitgevoerd onder het besturingssysteem linux daar dit een open-broncode-initiatief betreft. Hierbij werd gebruik gemaakt van de systeemoproep ptrace, alsmede van een extensie op ptrace die speciaal voor deze thesis werd ontwikkeld. Trefwoorden: input replay, linux, ptrace

6 Inhoudsopgave 1 Inleiding Probleemstelling Belangrijke aspecten van replay Input replay van programma s Inhoud Implementatie van Input Replay Situering Behoud van het systeemoproep-patroon Procescommunicatie Andere communicatie Partiële uitvoer Partiële invoer Procescontext Recording Klassen van systeemoproepen Het opslaan van de replay-data Heisenbugs Replay Signalen Replay configuratiebestanden Monitoring onder Linux Proces Trace systeemoproep Uitbreidingen Implementatie Gebruik Input replay onder Linux Ontwerp van de replay-module Het gebruik van de replay-module Besluit 54 A De bijgeleverde CD-ROM 55 B Een codefragment uit de replay-module 56 C Kernel tools 59 iv

7 INHOUDSOPGAVE v Bibliografie 60 Lijst van figuren 61 Lijst van tabellen 62 Index 63

8 Hoofdstuk 1 Inleiding Zoals reeds door M. Ronsse en K. De Bosschere [8] gesteld, is de theoretische basis, nodig tot input replay, vrij beperkt. Het is vooral de replay van parallellisme die een belangrijk onderzoeksdomein vormt. Zelfs interactie tussen replay van input en replay van parallellisme is af te zwakken tot input replay zonder enige vorm van parallellisme daar men onder sequenciëring het parallellisme ten aanzien van de input replay geheel kan elimineren. Desalniettemin zal hierop een uiteenzetting volgen dewelke ertoe dient bij te dragen een basis te leggen voor een implementatie van input replay. 1.1 Probleemstelling Samen met de steeds toenemende capaciteit van de huidige generatie computersystemen, neemt ook de omvang van de software toe. De door Tanenbaum [9] geformuleerde eerste wet van software : Adding more code adds more bugs laat impliceren dat het aantal bugs in (systeem)software evenredig oploopt. De behoefte aan krachtige debug-tools is dan ook steeds schrijnender. Belangrijk hierbij zijn de zogenaamde cyclische debuggers. Deze zullen een programma telkens opnieuw heruitvoeren met dezelfde invoer, resulterend in steeds dezelfde uitvoer, speurend naar bugs van algoritmische aard. Doorgaans doet men hiertoe beroep op breakpoints. Bijgevolg stelt het probleem zich dat men een bepaald proces steeds van identiek dezelfde data wenst te voorzien. Dit zal dan ook door input replay worden bewerkstelligd. Niet enkel cyclische debuggers zijn afhankelijk van input replay, ook onderzoek naar niet-determinisme binnen parallelle en gedistribueerde processen vraagt hierom. Men is hier doorgaans niet gebrand op het bekomen van steeds dezelfde uitvoer zoals bij het cyclisch debuggen het geval is, maar men zal net de verschillen in uitvoer wensen te focussen. Deze verschillen duiden op niet-deterministische elementen binnen het betreffend proces. Bijgevolg is input replay ook een zeer belangrijk aspect bij de detectie van data races binnen een parallelle uitvoering. Verder kan men input replay ook aanwenden bij de bestudering van programmauitvoeringen onder deels wijzigende data-invoerstromen. Slechts één enkele datastroom 1

9 HOOFDSTUK 1. INLEIDING 2 uit de invoer van een programma wijzigen, laat toe selectief bepaalde delen van het betreffend proces uit te testen en te analyseren. Een dynamische implementatie van input replay is bijgevolg bepalend voor de bruikbaarheid van deze laatste. Het utopische doel deterministische heruitvoering, dewelke gelijktijdige replay van input en parallellisme omvat, vereist tevens de hier behandelde replay-faciliteiten. Opgemerkt dient dus te worden dat input replay slechts een klein deel uitmaakt van een veel grotere doelstelling, namelijk een complete eliminatie van niet-deterministische factoren binnen heruitvoering van software. 1.2 Belangrijke aspecten van replay Een perfecte replay bestaat niet. Een heruitvoering verschilt steeds van zijn origineel daar het tijdstip waarop deze gebeurt reeds een factor van verschil uitmaakt. Enkel wanneer we onze waarnemingsgranulariteit 1 grover maken, kunnen we tot de uitspraak een perfecte replay komen. Dit betekent concreet dat we steeds iets minder nauwkeurig dienen waar te nemen dan de werkelijkheid. Binnen het domein van een computerprogramma zal dit inhouden dat we over een perfecte replay spreken indien het resultaat van elke instructie bij heruitvoer hetzelfde is als bij de originele uitvoering. Ook al is het tijdstip waarop dit gebeurt niet meer hetzelfde. In dit kader kan men twee soorten waarnemingsgranulariteiten onderscheiden: De maat van replay die het replay-systeem nodig acht om in een gevraagde replay te voorzien. Wanneer het replay-systeem een gaande replay niet meer als perfect beschouwt, zal de replay-module de gaande replay als onhoudbaar beschouwen. De replay wordt in dit geval stopgezet. Doorgaans zal deze maat onderdeel uitmaken van de specificaties waarnaar het betreffende replay-systeem werd ontwikkeld. De maat van replay waarmee een waarnemer/gebruiker de replay als perfect zal bestempelen. Elke gebruiker kan zijn eigen eisen en bijgevolg zijn eigen maat hebben ter aanduiding van een geslaagde replay. Merk hierbij op dat een gebruiker een replay-systeem slechts bruikbaar zal vinden wanneer zijn maat tot waarnemen van een perfecte replay gelijk aan of grover is dan die gehanteerd door het replay-systeem. Uiteraard kan het zijn dat een replay correcter gebeurt dan nodig geacht door het replay-systeem, doch dit is geen vereiste. Hetzelfde geldt voor de correctheid zoals gedicteerd door de gebruiker van het replay-systeem. Een perfecte replay, zoals bepaald door een waarneming met fijne granulariteit, zal steeds een perfecte replay impliceren zoals waargenomen via een grovere granulariteit, met als uiterste een waarneming die zich beperkt tot het starten en stoppen van het te replayen proces. Het omgekeerde is niet steeds waar, met als uiterste een incorrecte replay wegens steeds voortvloeiende tijd die niet te replayen valt. 1 Granulariteit vertaald van het Engelse granularity.

10 HOOFDSTUK 1. INLEIDING 3 De waarnemingsgranulariteit is gerelateerd aan het abstractieniveau waarop we effectief replayen. De waarnemingsgranulariteit is echter een maat waarmee we een replay beschouwen, terwijl het abstractieniveau duidt op het niveau waarop we effectief replayen. Deze twee hoeven niet noodzakelijk samen te vallen. Doorgaans zal een hoger abstractieniveau leiden tot kleinere replay-bestanden 2 [8], ten nadele van de correctheid van de replay zoals door het replay-systeem algoritmisch gemeten via het vooraf ingestelde waarnemingsniveau. Een replay-systeem heet pragmatisch correct indien zijn abstractieniveau, gebruikt bij replay, overeenkomt met het abstractieniveau nodig om een programma zijn normale verloop te laten aannemen. Een fijnere replay-verzorging door het replay-systeem zou nutteloos zijn daar het programmaverloop hierdoor niet verder beïnvloed wordt. Het kan zelfs zo zijn dat een te laag abstractieniveau, aangewend door het replay-systeem, ongewenst is voor de gebruiker. Concreter zal een replay-gebruiker doorgaans meer hebben aan de foutmelding: de functie kreeg een illegale waarde -1 als parameter, dan aan de melding: het register xyz kreeg de illegale waarde -1 toegekend. Dit omdat het door het replay-systeem gehanteerde abstractieniveau en daarmee gerelateerde waarnemingsniveau te laag ligt. Merk verder op dat een te laag abstractieniveau de originele uitvoering van het te replayen systeem zelf zodanig zou kunnen beïnvloeden, dat deze uitvoering compleet verschilt van een uitvoering waarbij we het replay-systeem betreffend proces niet laten monitoren. Hierbij worden we geconfronteerd met zogenaamde Heisenbugs, veroorzaakt onder het monitoren door het replay-systeem. Deze bugs zijn deterministisch of nietdeterministisch geaard 3. De deterministische vorm onstaat door het probe effect van het replay-systeem, de niet-deterministische vorm doorgaans door beïnvloeding van het parallellisme van betreffend proces. De recording overhead door het replay-systeem dient bijgevolg zo klein mogelijk te worden gehouden, zodat het gemonitoorde proces zo weinig mogelijk wordt beïnvloed. Ideaal zou zijn dat de recording overhead zó laag is, dat we het replay-systeem steeds alle processen actief laten tracen en dus als vast onderdeel van de werkomgeving maken. Hierdoor zou elke anomalie, die zich tijdens bedrijf voordoet, steeds door het replaysysteem worden gedetecteerd en mogelijk gereplayet voor nader onderzoek. Elk abstractieniveau kent zijn eigen overhead, bepaald door afweging tussen space en time overhead. De time overhead wordt veroorzaakt door de belasting van de processor(en) met het monitoren door het replay-systeem. Deze overhead kan een bepaalde impact hebben op de uitvoering van processen die men wenst te tracen. Verder kunnen restricties, opgelegd door het replay-systeem zelf, ook zorgen voor een time overhead. De space overhead wordt doorgaans veroorzaakt door de opbouw van het replaybestand. Het gebruik van tijdelijke bestanden door het replay-systeem zal hier echter ook een aandeel in hebben. 2 Worden ook nog trace-bestanden genoemd. 3 In sommige literatuur stelt men dat Heisenbugs louter niet-deterministisch geaard zijn. Doch sommige bugs door beïnvloeding zijn perfect voorspelbaar.

11 HOOFDSTUK 1. INLEIDING 4 Een grotere time overhead leidt doorgaans tot kleinere replay-bestanden daar men, door het additionele tijdsverbruik, selectiever de data kan stockeren nodig voor de replay. Doch echter kent het replay-bestand een maximale compactheid en zal additionele time overhead op een gegeven moment niet meer resulteren in een reductie van de space overhead. In sommige gevallen kan het zijn dat voor een bepaalde afweging tussen de space en time overheads een lager abstractieniveau attractiever is qua overhead dan een hoger abstractieniveau. In dit geval is het verantwoord het abstractieniveau, gehanteerd door het replay-systeem, te verlagen. Andersom is dit echter niet toelaatbaar daar men hierdoor de specificaties van het replay-systeem zou schenden. 1.3 Input replay van programma s De aard van een programma is sterk bepalend voor de manier waarop we input replay dienen te implementeren. We zullen vooreerst dan ook de programma s in hun drie categorieën onderverdelen. Sequentiële programma s Het is belangrijk onderscheid te maken tussen programma s die parallelle code bevatten en programma s die deze code ook effectief kunnen uitvoeren binnen een proces. Elk proces begint immers met een sequentieel verloop en kan pas later in de uitvoering tot parallellisme komen. Vooraleer we aan input replay toe zijn, moeten we de soorten invoer die een programma kent, analyseren. Er zijn twee soorten invoer te onderscheiden. Externe invoer die wordt veroorzaakt doordat het proces via (onder andere) het besturingssysteem met andere deelsystemen communiceert. Deze is bij alle programma s niet-deterministisch van aard. Het zal bijgevolg nodig zijn deze vorm van invoer te kunnen replayen indien we een perfecte replay wensen. Externe invoer wordt veroorzaakt binnen het proces zelf. De verschillende instructies die binnen het proces worden uitgevoerd, zullen namelijk de (globale) datastructuren van het proces lezen (en schrijven) wat een vorm van invoer is. Bemerk dat bij sequentiële programma s deze vorm van invoer perfect deterministisch is. Deze interne invoer wordt bij sequentiële programma s namelijk geheel gedicteerd door de code van het programma zelf. Parallelle programma s Dit zijn programma s die tijdens de uitvoering verschillende threads al dan niet binnen dezelfde virtuele geheugenruimte van betreffend proces laten lopen. Indien verschillende threads binnen dezelfde virtuele geheugenruimte via globale datastructuren voor interne invoer zorgen, kan dit een additionele bron van nietdeterminisme zijn, naast het niet-determinisme veroorzaakt door de (normale) externe invoer. Het deterministische karakter van de interne invoer wordt hier namelijk niet meer louter en alleen bepaald door de code van het programma. Bij replay van parallelle programma s dienen we duidelijk te stellen wat het is wat we wensen te replayen.

12 HOOFDSTUK 1. INLEIDING 5 Binnen een parallel programma kan het wenselijk zijn van de verschillende processen die onderdeel uitmaken van het parallelle programma slechts één enkel proces te replayen. Indien deze verschillende processen allen elk hun eigen gescheiden virtuele adresruimte kennen, verloopt de communicatie tussen deze processen op externe wijze. Replay van één enkel proces hieruit is zoals de replay van sequentiële programma s. Indien het betreffende proces echter zijn virtuele adresruimte deelt met andere threads, dienen we ook de interne communicatie met deze andere threads te replayen, alsook de externe communicatie van deze andere threads. Het kan ook zijn dat we meerdere processen binnen het parallelle programma tegelijk wensen te replayen om de interactie tussen deze te bestuderen. Dit zal in deze scriptie echter niet worden behandeld. Gedistribueerde programma s Gedistribueerde programma s zijn er onder twee vormen. Het gedistribueerde karakter van het programma wordt voorzien door een bibliotheek, los van het eigenlijk besturingssysteem. Hierbij voorziet de kernel enkel in de communicatie, doorgaans via een netwerkstapel als TCP/IP. Het besturingssysteem zelf verzorgt het gedistribueerde binnen het programma. Dit zou zich in de kernel kunnen manifesteren door elk proces, naast zijn uniek proces-id, ook van een host-variabele te voorzien die aanduidt op welke host dit proces momenteel actief is. Afhankelijk van de klasse waaronder het gedistribueerde programma onder te brengen is, zal de input replay-module anders moeten geconstrueerd zijn. In het eerste geval zal men eigenlijk een inter-proces replay-module dienen te construeren, terwijl het tweede geval een replay-module vereist die sterk de kernel manipuleert om het gedistribueerde karakter van betreffend programma perfect te replayen. De replay van gedistribueerde programma s komt niet aan bod in deze scriptie. Replay van sequentiële programma s Een sequentiële programma-uitvoer ligt compleet vast door zijn code en invoerdata. Bijgevolg vereist een perfecte heruitvoering dat beide factoren constant blijven. Om de invoerdata onder verschillende heruitvoeringen gelijk te houden, moet men in input replay voorzien. Hierdoor zullen alle niet-deterministische elementen, die sequentiële programma s kennen, geëlimineerd zijn. Merk op dat vele omgevingen sequentiële programma s toelaten signalen te ontvangen wat tevens een bron van niet-determinisme vormt. De replay van deze signalen is echter onder te brengen bij replay van parallellisme. Input replay en parallellisme Wanneer we een perfecte replay van parallelle programma s wensen, zal het niet volstaan enkel de invoer van dit programma te replayen. Ons beperken tot input replay

13 HOOFDSTUK 1. INLEIDING 6 zal namelijk het niet-determinisme binnen het programma, veroorzaakt door het parallellisme zelf, niet kunnen elimineren. Slechts indien we ook het parallellisme binnen dit programma replayen, zullen we een perfecte replay kunnen verzekeren. Wanneer we in een parallellismeconservatie voorzien, zal de input replay zelfs niet eens complexer moeten gebeuren dan bij sequentiële programma s het geval was. Onder parallellismeconservatie zal het parallelle programma zich, ten aanzien van de input replay, namelijk als een fictief sequentieel programma voordoen. Dit houdt in dat de volgorde, waarin het parallelle programma om bepaalde invoer vraagt, tijdens de verschillende heruitvoeringen dezelfde blijft wanneer ook het parallellisme perfect gereplayet wordt. Elke aanvraag tot invoer door het parallelle programma zal hier gewoon een proces-id als extra karakteristiek hebben. Merk op dat parallellismeconservatie eigenlijk zelfs niet vereist is om een perfecte input replay te kunnen verzekeren. We dienen namelijk slechts alle invoer, die het programma kent, te conserveren. De externe invoer wordt geconserveerd zoals bij sequentiële programma s het geval is. Verder kent het parallelle programma ook nog niet-deterministische interne invoer. Deze vindt plaats tussen de verschillende threads van het programma langs de globale datastructuren. Deze interne invoer conserveren kan inderdaad worden bewerkstelligd via parallellismeconservatie, doch andere werkwijzen bestaan. Men spreekt in dit kader over ordering-based replay en content-based replay. Parallellismeconservatie valt onder ordering-based replay. Bij content-based replay-methoden zal men trachten de data-afhankelijkheden te conserveren. Hierdoor kan men ook het niet-determinisme binnen de interne invoer geheel elimineren. Een interessante methode die hieronder valt, associeert met elk data-object een versienummer. Elke schrijfoperatie verhoogt het versienummer van het betreffende data-object. Ook wordt het aantal leesoperaties van een bepaald data-object per versienummer bijgehouden. Tijdens de replay zal men elke leesoperatie ophouden tot wanneer het versienummer van het betreffend data-object overeenkomt met dat uit de record-fase. Ook wordt elke schrijfoperatie uitgesteld totdat het gewenste aantal leesoperaties voor het huidige versienummer van betreffende data-object bereikt is. De gekende methoden gebaseerd op content-based replay leveren allen een zeer slechte prestatie. In deze scriptie zullen dan ook enkel ordering-based replay-methoden worden behandeld. 1.4 Inhoud In een volgend hoofdstuk zullen de verschillende aspecten worden besproken die bij een implementatie van input replay komen kijken. Hoofdstuk 3 handelt over het monitoren van een proces onder het besturingssysteem linux. Verder wordt in hoofdstuk 4 de implementatie van de replay-module onder linux besproken.

14 Hoofdstuk 2 Implementatie van Input Replay In dit hoofdstuk zullen aspecten van input replay met betrekking tot de implementatie worden besproken, echter zonder specifiek naar de geschreven implementatie onder linux te verwijzen. 2.1 Situering invoer verwerking uitvoer (A) invoer verwerking uitvoer (B) invoer bewaren invoer verwerking uitvoer (C) bewaarde invoer Figuur 2.1: Invoer, verwerking en uitvoer Op bovenstaand schema (fig. 2.1 A) zien we hoe een programma van invoer wordt voorzien, die verwerkt en dit als uitvoer terug aan de gebruiker levert. De code van dit programma wijzigt gedurende verschillende uitvoeringen doorgaans niet; de invoer echter wel. Door deze laatste kan het programmaverloop en bijgevolg de uitvoer steeds een andere gedaante hebben. Wat we bij input replay wensen te bekomen, is het programma steeds van identiek dezelfde invoer te voorzien om zo het gedrag van dit proces beter te kunnen bestuderen. Om het programma van identiek dezelfde invoer te voorzien, dienen we eerst een bepaalde invoer van dit programma vast te leggen. Dit zal gebeuren in een eerste fase, de record-fase (zie fig. 2.1 B). Hierbij laten we het proces gewoon zijn werk verrichten waarbij we tevens de invoer aftappen en opslaan in een zogenaamd replay-bestand voor later gebruik. Dit alles is het werk van een tracer wat onderdeel is van de replay-module. In een volgende fase, de replay-fase, gaan we deze bewaarde invoer opnieuw gebruiken als effectieve invoer voor het programma. We laten hiertoe (zie fig. 2.1 C) het proces 7

15 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 8 gewoon lopen, maar blokkeren de normale invoerkanalen van dit proces en voorzien het van vervangende invoer die werd opgeslaan in de record-fase. Bovenstaande conceptuele schema s, afgebeeld in fig. 2.1, zijn uiteraard slechts een zeer grove benadering en zullen vervolgens verder worden uitgewerkt. Een iets realistischere situatie toegepast op het huidige model van besturingssystemen vinden we terug in fig Hierbij gebeurt alle communicatie met de buitenwereld proces systeemoproep besturingssysteem proces systeemoproep Figuur 2.2: Processen en het besturingssysteem steeds via het besturingssysteem. Zowel de in- als uitvoer van een bepaald programma zal via het besturingssysteem gebeuren. De zogenaamde systeemoproepen zijn hiertoe het medium. Via de systeemoproepen zal een bepaald proces zijn invoer achterhalen, deze bewerken en vervolgens opnieuw via systeemoproepen als uitvoer teruggeven aan de gebruiker. Wat een proces onder buitenwereld verstaat kan zijn: een ander gebruikersproces binnen dezelfde machine een deel van het besturingssysteem zelf (bestandsinvoer en -uitvoer) een proces op een andere machine (netwerkinvoer en -uitvoer) Het is belangrijk hierbij op te merken dat elke vorm van communicatie met een ander proces steeds via de systeemoproepen van het besturingssysteem zelf gaat. Om de invoer in de record-fase op te nemen, zullen concreter deze systeemoproepen worden afgetapt. Vervolgens dienen we in de replay-fase de systeemoproepen parametrisch te wijzigen opdat ze zich, voor het te replayen proces, identiek zouden gedragen als in de record-fase. 2.2 Behoud van het systeemoproep-patroon Teneinde de replay-fase tot een goed einde te brengen, zullen we er verzekerd moeten van zijn dat het patroon, waarmee het proces in de record-fase systeemoproepen uitvoert, identiek is in de replay-fase. Behoud van het systeemoproep-patroon is bijgevolg een zeer belangrijk aspect van input replay.

16 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 9 Wanneer hieraan niet voldaan wordt, komt een correcte replay in het gedrang. Onderstel namelijk het volgende geval: Een proces in de record-fase haalt via een systeemoproep slechts éénmaal een byte op. Vervolgens beslist dit proces in de replay-fase om ditmaal via twee systeemoproepen twee bytes op te halen. Wat dienen we deze tweede systeemoproep dan te laten teruggeven? In de record-fase hebben we namelijk slechts één enkele byte opgeslaan om in de replay-fase als invoer te gebruiken. Die tweede byte improviseren is niet echt meer replayen. Indien we op zó een punt komen in de replay-fase, moeten we de replay van de invoer bijgevolg stopzetten. We kunnen immers niet meer verzekeren dat het proces een perfecte replay doormaakt. De replay heet dan onhoudbaar. In zo n geval koppelen we de tracer los van het proces. Dit proces laten we vervolgens weer zijn gewone invoer aannemen, in geval dit uiteraard nog enigszins mogelijk is. 2.3 Procescommunicatie Uit voorgaande stellen we vast dat er heel wat problemen kunnen optreden bij input replay. Deze problemen zijn te wijten aan communicatieproblemen die het proces kent. In deze sectie gaan we de procescommunicatie dan ook eens nader bestuderen. Er zijn twee grote klassen van communicatie mogelijk: externe en interne communicatie. Deze zullen in de volgende subsecties worden toegelicht. Externe procescommunicatie Deze vorm is de normale vorm van communicatie 1. Hierbij zal een proces (zie fig. 2.2) via de systeemoproepen met een ander proces gaan communiceren. Dit proces kan op de lokale machine draaien, maar het kan ook dat dit proces op een andere machine draait die via een netwerk in verbinding staat. Het feit of dit andere proces al dan niet ook lokaal draait, maakt voor het te replayen proces eigenlijk weinig uit; het is gewoon een andere vorm van invoer/uitvoer, maar het is en blijft óók invoer/uitvoer. De meeste besturingssystemen zorgen zelfs voor een transparant gebruik van netwerkcommunicatie met een ander proces. Concreter gaat men hiertoe doorgaans een connectie naar communicatiemogendheden via descriptoren tot stand brengen. Vervolgens worden met behulp van deze descriptoren algemene systeemoproepen aangewend om in de eigenlijke in- en uitvoer te voorzien. Onder linux bijvoorbeeld aanvaarden de systeemoproepen read, write en close descriptoren van zowel bestanden als netwerkconnecties. Interne procescommunicatie Deze klasse van communicatie kan voor veel problemen zorgen indien we de externe procescommunicatie exact wensen te replayen. Figuur 2.3 zal deze vorm van commu- 1 Verwar dit niet met SYSV IPC, wat slechts een deel uitmaakt van de externe procescommunicatie.

17 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 10 nicatie trachten te verduidelijken én ook waarom deze vorm de externe communicatie kan beïnvloeden. proces data thread 1 thread 2 besturingssysteem systeemoproepen Figuur 2.3: Meerdere threads binnen een proces Stel dat een proces meerdere threads heeft draaien binnen één en dezelfde geheugenruimte. In dit geval zullen deze verschillende threads allen dezelfde globale datastructuren kunnen gebruiken en wijzigen. Zoals gekend kan dit leiden tot race-condities [9]. De meest gekende race-conditie is die waarbij twee threads een teller, die voorheen op nul stond, trachten te verhogen. Dit zal vaak tot een waarde 2 voor de teller leiden, maar in geval van races ook tot waarde 1. Dit is te wijten aan het mogelijk niet-atomisch zijn van een increment-statement waarmee elk van deze threads de teller wensen te verhogen. Zo een increment-statement werkt doorgaans in twee stappen. In een eerste stap zal dit statement de oude waarde van de teller uit het geheugen lezen. In een tweede stap zal deze de zonet gelezen waarde met één verhogen en opnieuw wegschrijven naar het geheugen. Indien nu de eerste thread door het besturingssysteem, na het lezen van de teller, wordt onderbroken ten voordele van de tweede thread, zullen ze beiden de waarde nul uit de betreffende teller lezen. Vervolgens zullen beide threads deze met één verhogen en terug wegschrijven naar het geheugen. Dit zal resulteren in een teller met waarde 1 in plaats van de gewenste waarde 2. Als het proces (dit is één der threads) deze teller nu aanwendt als aantal te plegen systeemoproepen, dan zal dit ertoe leiden dat in sommige gevallen 2 systeemoproepen zullen plaatsvinden en in andere gevallen slechts 1 systeemoproep. Bovenstaande situatie kan bijgevolg leiden tot het verbreken van het systeemoproeppatroon (zie sectie 2.2), wat de replay onhoudbaar maakt. Belangrijk hierbij op te merken is, dat het correct gebruik van mutexes en andere lock-methoden hieraan geen uitkomst biedt. Een lock op een variabel zal er weliswaar voor zorgen dat de data die deze lock dient te beschermen consistent blijft, maar het verkrijgen van deze lock zélf is nog steeds een niet-deterministisch element. En indien het proces, afhankelijk van het verkrijgen van deze lock (wat een vrij raar gedrag zou te noemen zijn), een systeemoproep al dan niet doorvoert, dan zullen we opnieuw het systeemoproep-patroon mogelijk verbreken. Bovenstaande gevallen zijn doorgaans toe te schrijven aan de scheduler van het besturingssysteem die zich nooit hetzelfde zal gedragen in replay- als in record-fase. Doordat de scheduling tussen de verschillende concurrerende threads binnen het proces steeds verschilt, zal het verkrijgen van locks (of de toegang tot onbeschermde data) steeds een

18 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 11 element van willekeur zijn. Aan dit probleem is eventueel te verhelpen door vanaf het moment dat een proces meerdere threads heeft de inter-thread scheduling van het proces zelf ook op te slaan om deze later in de replay-fase ook te kunnen replayen. Merk op dat dit enkel zinvol is indien het proces meerdere threads heeft. Wanneer er slechts één enkele thread binnen het proces draait, hebben we uiteraard ook taakwisselingen (deze zijn er steeds bij een preëmptive kernel, zoals alle huidige besturingssystemen geconstrueerd zijn) maar het proces wordt hierdoor niet beïnvloed. Dus slechts bij meerdere threads binnen éénzelfde proces dienen we de scheduling op te slaan. En wel enkel dit deel van de scheduling die verantwoordelijk is voor de vreemde situaties zoals hierboven beschreven staan. Zo zal thread 1 thread 2 proces 1 proces 2 thread 1 t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 tijd Figuur 2.4: Een scheduling-schema bij twee processen voor het scheduling-schema uit fig. 2.4 slechts de scheduling-informatie op tijdstippen t 1, t 2, t 4, t 7 en t 8 dienen te worden bijgehouden. De informatie uit t 5 is nutteloos. Hier vindt weliswaar een taakwisseling naar proces 2 plaats, maar bij terugkeer naar proces 1 is het toch opnieuw zijn eerste thread die aan de beurt komt. Dus voor proces 1 is het dan alsof er niets is gewijzigd aan de situatie, althans voor wat de scheduling betreft. Bij multi-processor systemen zal men de scheduler extra restricties opleggen om bovenstaande voorgestelde werkwijze te kunnen hanteren: Threads van éénzelfde proces mogen nooit tegelijk op verschillende processoren actief zijn. Indien dit wel het geval zou zijn, dan volstaat het niet om enkel de scheduling te conserveren om het parallellisme correct te kunnen replayen. Het parallellisme bezit dan namelijk een veel fijnere granulariteit dan gedicteerd door de scheduler. In dit geval zouden we het gehele proces in single step modus moeten laten draaien, om zo exact de volgorde te weten waarin alle threads van het proces hun instructies uitvoeren. Een parallellisme-conservatie aan de hand van single step modus levert echter een zeer slechte prestatie, meer hierover onder Prestatie op pagina 31. De meest voor de hand liggende oplossing hiervoor bestaat erin de uitvoering van een proces (met al zijn threads) te beperken tot één enkele processor. Dit is uiteraard enkel vereist voor processen die we tracen in een record-fase. De scheduler moet zich dus, in geval van recording van een bepaald proces, voor dit proces tot één enkele processor beperken. Wanneer de scheduler zich niet aan de bovenstaande regel houdt, zullen we andere record-methoden voor de scheduling-conservatie moeten bedenken. Merk hierbij op dat het mogelijk is dat we door die scheduler-restrictie het betreffend proces zullen beïnvloeden en zó mogelijke niet-deterministische fouten de kans laten zich al dan niet te manifesteren. De beïnvloeding, door het proces in single step modus te laten draaien, is echter nog groter. Meer hierover vindt men onder Heisenbugs, paragraaf op pagina 21.

19 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 12 Het opslaan van het scheduling-patroon is een quasi onbegonnen werk. Men zou hiertoe in de diepste lagen van de kernel moeten controleren wanneer thread-scheduling plaatsvindt. Als het dan een scheduling betreft van het te recorden proces, dan moet het exacte moment waarop dit gebeurt worden opgeslaan. Dit exacte moment opslaan kan gebeuren door het bijhouden van de waarde van het instructiewijzerregister én het aantal keren dat de betreffende instructie reeds werd uitgevoerd. Dit laatste is nodig daar een instructie in een lus meerdere malen wordt uitgevoerd en in een functie meerder malen kan worden uitgevoerd. Tussen de verschillende uitvoeringen dienen we dan ook een onderscheid te kunnen maken. Het aantal uitvoeringen van een instructie op een bepaald geheugenadres kan op verschillende manieren worden achterhaald. De meeste processoren bieden de mogelijkheid hardware-matig het totale aantal uitgevoerde instructies bij te houden. Wanneer er echter geen hardware-oplossing beschikbaar is, zullen we ons moeten beroepen op een software-matige aanpak van het probleem. Hierbij wordt een SIC of Software Instruction Counter geconstrueerd. Deze teller laat toe exact te bepalen waar we ons in de uitvoering van een bepaald programma precies bevinden. Dit houdt in dat we het aantal uitvoeringen van een huidige instructie steeds kunnen achterhalen. Belangrijk hierbij op te merken is dat dit aantal uitvoeringen steeds bepaald wordt door het aantal achterwaartse sprongen dat het programma reeds genomen heeft. Een instructie kan namelijk slechts meerdere malen worden uitgevoerd indien er een achterwaartse sprong genomen werd. Bijgevolg volstaat het enkel de achterwaartse instructies in een programma te instrumenteren om een SIC te construeren. Dat we hierbij de basisblokken van een programma ongemoeid kunnen laten, zal sterk tot de minimale overhead van de SIC bijdragen [5]. Het enige nadeel van een software-oplossing is uiteraard dat we de code van het programma en van alle gebruikte bibliotheken dienen te instrumenteren. Bijgevolg is een hardware-oplossing meer gewenst. Het replayen van de scheduling kan op verschillende manieren gebeuren. Zo zouden we het bewaarde scheduling-patroon kunnen replayen door op de gepaste plaatsen, vóórdat we de replay aanvangen, breakpoints te plaatsen. Hierop kan de scheduler zich baseren om gepast tussen de threads van betreffend proces te wisselen, dit uiteraard naast de taakwisselingen die moeten gebeuren voor de overige processen binnen het systeem. De scheduler mag een dergelijke taakwissel slechts laten plaatsvinden wanneer het opgeslane uitvoeringsgetal van betreffende instructie overeenkomt met het aantal keren dat de breakpoint reeds werd bereikt. Verder dient te worden opgemerkt dat bij het gebruik van breakpoints de code van het proces zelf moet worden gewijzigd. Op sommige architecturen kan dit tot conflicten met de instructie-cache leiden. De replay-module, voor deze thesis ontwikkeld, ondersteunt meerdere threads niet qua scheduling-conservatie. Dit wil echter niet zeggen dat een proces met meerdere threads niet kan worden gereplayet. Wel is het zó dat het systeemoproep-patroon sneller zal worden doorbroken dan in het geval de scheduling zelf ook zou worden geconserveerd in de replay-fase. 2.4 Andere communicatie Naast de communicatie via de systeemoproepen kan een proces nog enkele andere resources aanspreken om een bepaalde vorm van input (en/of output) te bekomen.

20 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 13 Deze verschillende resources zullen hier worden besproken. I/O-poorten Stel dat een proces zeer low-level gaat qua programmering van de randapparaten, dan zal het beroep doen op de input/output-poorten. Hierbij kan het leesresultaat van deze poorten in de replay-fase verschillen van deze uit de record-fase. In geval er een afhankelijkheid bestaat met het systeemoproep-patroon, kan deze laatste opnieuw worden verbroken. Dit zal opnieuw leiden tot onhoudbare replay-situaties. Zo een afhankelijkheid is in volgend programma ingebouwd. ; Port system call dependency demo. (linux) ; The Netwide Assembler NASM 0.98 section.data msg db "Hello World!", 0x0a msg_size equ $ - msg PORT equ 0x80 section.text global _start ; ELF entry point _start: mov eax, 101 ; ioperm mov ebx, PORT ; from mov ecx, 1 ; num mov edx, 1 ; turn_on int 0x80 ; kernel call in al, PORT xor ebx, ebx and eax, 1 jz.exit mov eax, 4 ; write mov ebx, 1 ; fd = stdout, and error code 1 on.exit mov ecx, msg ; buffer ptr mov edx, msg_size ; buffer size int 0x80 ; kernel call.exit: end mov eax, 1 ; exit, ebx = exit code int 0x80 ; kernel call Dit programma leest een bepaalde I/O-poort (0x80) en zal afhankelijk van de bekomen waarde al dan niet Hello World! op de console afprinten. Verschillende oplossingsmethoden zijn te bedenken om aan dergelijke afhankelijke opstellingen het hoofd te bieden. Deze worden hieronder kort besproken.

21 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 14 Blokkeren van de I/O-poorten. Zowel in de record- als in de replay-fase kunnen we gewoonweg het proces de toegang tot de poorten ontzeggen. Uiteraard is dit niet echt een zeer zinvolle methode te noemen. Het probleem is niet echt opgelost door het proces in de record-fase restricties op te leggen (Heisenbugs). Monitoren van de I/O-poorten. Sommige processoren zijn van de functionaliteit voorzien dat er bij poorttoegang door een bepaald proces een exceptie kan worden gegenereerd. We zouden via een aangepaste exceptie-handler dan het resultaat van de poorttoegang in de recordfase kunnen opslaan en deze in de replay-fase terug in het proces injecteren. In de replay-module, ontwikkeld bij deze thesis, werd deze vorm van communicatie ongemoeid gelaten met uiteraard alle mogelijke gevolgen vandien. I/O-geheugen Indien een I/O-geheugenblok gemapt is in de geheugenruimte van het proces dat we wensen te replayen, zullen we analoge maatregelen dienen te treffen zoals bij I/Opoorten. Hierbij zetten we de geheugenprotectiebits in het paging-subsysteem zodanig dat bij elke toegang tot de I/O-geheugengebieden opnieuw een exceptie wordt gegenereerd. Via een aangepaste exceptie-handler kunnen we vervolgens de nodige data in de record-fase opslaan en in de replay-fase deze data terug injecteren in het proces. In de replay-module, ontwikkeld bij deze thesis, werd deze vorm van communicatie ongemoeid gelaten met uiteraard alle mogelijke gevolgen vandien. De processor Sommige processoren kunnen zelf ook voorzien in data die steeds verschillend is en moeilijk te replayen. Zo bevat de Intel Pentium processorklasse een time-stamp counter[3] dewelke elke klokpuls met één wordt verhoogd. Een proces kan deze teller lezen via de instructie RDTSC die de huidige time-stamp counter in EDX:EAX wegschrijft. Ook hier kan een proces zijn systeemoproep-patroon in de replay-fase verbreken door zich afhankelijk van deze waarde op te stellen. Zo een opstelling is hieronder weergegeven. ; Time-stamp counter system call dependency demo. (linux) ; The Netwide Assembler NASM 0.98 section.data msg db "Hello World!", 0x0a msg_size equ $ - msg section.text global _start ; ELF entry point _start: rdtsc ; tsc -> edx:eax xor ebx, ebx

22 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 15 and eax, 1 jz.exit mov eax, 4 ; write mov ebx, 1 ; stdout mov ecx, msg ; buffer mov edx, msg_size ; buffer size int 0x80 ; kernel call.exit: end mov eax, 1 ; exit, ebx = exit code int 0x80 ; kernel call Dit programma leest de time-stamp counter (van de huidige processor) en zal afhankelijk van de bekomen waarde al dan niet de zin Hello World! op de console afprinten. Het probleem dat zich in bovenstaande code manifesteert, is op te lossen door de timestamp disable (TSD) flag in het register CR4 te zetten. Hierdoor zal het programma, bij het opvragen van de time-stamp counter, een #GP exceptie opwerpen. In de exceptiehandler (die op kernel-niveau draait) kunnen we vervolgens kijken of de instructie die de fout veroorzaakte wel degelijk een RDTSC was. Indien dit het geval is, moeten we een speciale afhandeling voorzien: In de record-fase zullen we de time-stamp counter effectief lezen door zelf een RDTSC uit te voeren. Vervolgens gaan we het resultaat hiervan in het replaybestand opslaan en dit tevens injecteren in EDX:EAX van het betreffende proces. In de replay-fase zullen we de time-stamp counter, die in de record-fase werd opgeslaan, terug in EDX:EAX injecteren. In de replay-module, ontwikkeld bij deze thesis, werd bovenstaande niet geïmplementeerd daar dit diepgaande wijzigingen van de kernel zou vereisen. Naast deze time-stamp counter heeft elke processorklasse van Intel steeds wel enkele extra registers die voor dergelijke ongemakken kunnen zorgen. Indien elk van deze registers via een #GP te beschermen is, kunnen we steeds de werkwijze, zoals hierboven beschreven staat, hanteren om ook de instructies die betrekking hebben op deze registers te kunnen replayen. Het zou wel vrij veel werk vergen om alle references van Intel te gaan lezen, speurend naar dergelijke registers en hiervoor dan steeds oplossingen te bedenken. De behandeling van de time-stamp counter diende dan ook slechts als voorbeeld om te duiden op het feit dat de processor zelf ook een bron van niet-determinisme kan zijn. 2.5 Partiële uitvoer In de replay-fase gaan we, zoals reeds uit fig. 2.1 (p. 7) blijkt, de echte invoer blokkeren en het proces voorzien van tevoren opgeslane invoer. Er is echter nog niets vermeld omtrent de uitvoer en we hebben impliciet aangenomen dat deze in de replay-fase ook

23 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 16 gewoon zijn taak blijft doen, daar we aan een blackbox-proces niets hebben. Dit is niet steeds gewenst. Via een voorbeeld trachten we dit te verduidelijken. Stel dat het betreffende proces als één van zijn uitvoeroperaties een INSERT in een tabel uit een databank doorvoert. Eén van de basisregels voor relationele databanken eist dat elke rij binnen een bepaalde tabel (relatie) uniek dient te zijn. Indien nu dit programma in zijn record-fase deze rij reeds wegschreef, is het ongewenst dat dit in de replay-fase nog eens zou gebeuren. Dit zou namelijk leiden tot een inconsistente databank. Om nog een voorbeeld aan te halen: Stel dat we via de replay-module een bepaald proces wensen te debuggen. Dit proces heeft in de record-fase een robotarm, die via het netwerk wordt bestuurd, laten crashen. Nu is het zo dat we in de replay-fase waarin we dit proces gaan bestuderen om te kijken waar het fout liep die robotarm niet opnieuw willen laten crashen. In dit voorbeeld is het vereist dat we de netwerkuitvoer kunnen blokkeren tijdens de replay-fase. We dienen bijgevolg over de mogelijkheid te beschikken om de uitvoer gedeeltelijk te blokkeren (zie fig. 2.5). invoer verwerking uitvoer bewaarde invoer Figuur 2.5: Partiële uitvoer Concreet moeten systeemoproepen die instaan voor de uitvoer in de replay-fase van instelbare permeabiliteit worden voorzien en dit voor uitvoer die tot inconsistenties kan leiden of onomkeerbare gevolgen met zich meedraagt. 2.6 Partiële invoer Analoog kunnen we tijdens de replay-fase ook de invoer mogelijk uit de oorspronkelijke resources wensen te halen in plaats van uit het replay-bestand zelf. De reden hiertoe verschilt wel van die bij de partiële uitvoer. Bij de invoer zouden we dit namelijk toelaten om de grootte van het replay-bestand enigszins beperkt te houden. Wat we namelijk kunnen terughalen uit de originele systeembronnen, dienen we in de recordfase niet op te slaan in het replay-bestand. Dit kan heel wat plaats uitsparen. De voorwaarde hiertoe is echter wel dat deze systeembronnen ook in de replay-fase aanwezig dienen te zijn en tevens ongewijzigd. De aanwezigheid kunnen we vrij makkelijk achterhalen in de replay-fase. Het al dan niet gewijzigd zijn, is daarentegen niet te achterhalen daar de originele inhoud niet werd opgeslaan om plaats te besparen. Die inhoud wel opslaan, louter en alleen om te kunnen verificeren, is vrij banaal omdat we hierdoor opnieuw ons replay-bestand laten uitzetten in grootte. Wat eventueel wel kan, is een checksum of een CRC-32 opslaan ter verificatie. Toch kan het met het oog op het debuggen van een bepaald proces soms handig zijn dat men een bepaalde vorm van input toelaat om tijdens de replay-fase anders te zijn. Zo kan men het gedrag van het proces op de wijziging van deze ene invoerstroom bestuderen. Ook hiervoor zou men partiële invoer kunnen appreciëren.

24 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 17 Verder valt op te merken dat verschillende types van invoer onder deze partiële herbruikbaarheid kunnen vallen. Zo kent linux (onder andere) bestandsinvoer, bestandsmapping en netwerkinvoer. 2.7 Procescontext Belangrijk bij input replay is ook het geheel eens te bekijken in functie van de procescontext. Elk proces bezit in wezen twee verschillende contexten. Zo is er de context in user mode en de context in kernel mode. Deze twee zullen in volgende subsecties worden behandeld. User mode context Deze context omvat hoofdzakelijk de inhoud van de algemene registers van het proces, alsook enkele registers met betrekking tot de geheugentoegang. Het is deze context die de scheduler bij elke taakwisseling dient op te slaan en naderhand te herstellen, opdat het proces zonder problemen zou kunnen verder werken. Onder deze categorie vallen ook de registers van additionele verwerkingseenheden zoals co-processoren. Deze registers worden door de meeste schedulers (zoals die van linux) slechts opgeslaan indien de betreffende functionele eenheid ook effectief door het proces wordt gebruikt. Wanneer we een exacte replay wensen, dewelke algoritmisch aan de hand van het systeemoproep-patroon makkelijk te verificeren is, zal de user mode context van betreffend proces tijdens elke systeemoproep in replay-fase gelijk moeten zijn aan de context zoals die was in record-fase. Kernel mode context Deze context is voor het proces niet onmiddellijk zichtbaar (wat de naam reeds deed vermoeden). Toch is deze vorm van procescontext van een niet te onderschatten belang voor het correct replayen van een proces. Dit zal worden verduidelijkt aan de hand van een voorbeeld. Indien een proces extra geheugen wenst om bepaalde datastructuren te stockeren, zal dit doorgaans gebeuren via een systeemoproep naar de kernel toe. De kernel zal hierop (hopelijk) reageren door in het geheugengebied van betreffend proces een blok nieuw geheugen te mappen. De effectieve implementatie hiervan doet er niet echt toe. Wat wel belangrijk is: een geheugengebied dient eerst door de kernel te worden gemapt vooraleer het door het user-proces kan worden gebruikt. Als het proces ongemapt geheugen gaat adresseren, zal de kernel doorgaans een exceptie genereren en het proces beëindigen onder een segmentatiefout. In de replay-fase zullen we de systeemoproep, die instaat voor het mappen van geheugen, opnieuw zijn werk moeten laten doen. Anders zal het proces, ondanks de aanvraag tot mappen van een nieuw geheugengebied, een geheugenfout maken bij toegang tot dit geheugen. Dit daar de gepaste kernel-datastructuren, die instaan voor het mappen van geheugengebieden, niet werden aangemaakt. Meer zelfs, we dienen de kernel duidelijk

25 HOOFDSTUK 2. IMPLEMENTATIE VAN INPUT REPLAY 18 te maken dat we exact dezelfde geheugen-mapping wensen. Maar is ditzelfde geheugengebied nog wel beschikbaar in de replay-fase? Misschien heeft een ander proces dit vóór ons reeds opgeëist 2. Uiteraard is dit, zoals reeds vermeld, sterk afhankelijk van de implementatie van de geheugentoekenner die in de kernel werd voorzien. Linux laat ons toe om aan bovenstaand probleem op een vrij makkelijke manier het hoofd te bieden. Algemeen kan men stellen dat resource-allocaties die, indien niet doorgevoerd tijdens de replay-fase, tot excepties kunnen leiden dus wel dienen te worden volbracht tijdens de replay. Een belangrijke opmerking hierbij is dat een perfecte replay van het proces daarom niet onmiddellijk een perfect dezelfde kernel mode context vereist. Bij replay moet enkel de user mode context exact dezelfde zijn als in de record-fase. Merk echter op dat het proces in de replay-fase denkt dat het van exact dezelfde kernel mode context is voorzien. We zullen dus, tijdens de replay, dienen te mappen tussen wat het proces denkt als kernel context te hebben én de effectieve replay-kernel context. 2.8 Recording In deze sectie gaan we na wat er zoal in de record-fase moet worden opgeslaan. Uiteraard zal dit niet méér zijn dan nodig is om in de replay-fase het systeemoproep-patroon niet te doorbreken, daar dit het enige algoritmische criterium vormt tot een correcte replay. De systeemoproepen vormen dé manier om een proces van invoer te voorzien. Het zijn het dan ook datastromen uit deze systeemoproepen die we zullen opslaan in het replay-bestand. Om het replay-bestand in de record-fase zo efficiënt mogelijk te kunnen construeren, zullen we eerst en vooral de systeemoproepen in hun verschillende klassen onderverdelen Klassen van systeemoproepen De systeemoproepen van alle doorsnee besturingssystemen 3 die heden beschikbaar zijn, zijn in 3 categorieën onder te verdelen. Ze zijn hieronder weergegeven. 1. Systeemoproepen die enkel een return code weergeven. De systeemoproepen van de meeste besturingssystemen leveren stééds een return code terug, ter aanduiding van het al dan niet lukken van de gevraagde systeemoperatie. Nu is het zo dat sommige systeemoproepen verder niets anders terugleveren, waardoor ze in deze categorie zijn onder te brengen. 2. Systeemoproepen die een gekend geheugengebied teruggeven aan het user proces, meestal naast het leveren van een return code. De geheugengebieden die deze 2 Dit andere proces zou de tracer kunnen zijn indien de replay-module zodanig geconstrueerd is dat het te tracen proces en de tracer in éénzelfde virtuele adresruimte worden uitgevoerd. 3 Voornamelijk de UNIX-varianten duid ik hier.