DOUG LLOYD: Okay GDB. Hvad er det præcist? Så GDB, som står for GNU Debugger, er en virkelig fantastisk værktøj, som vi kan bruge til at hjælpe os med debug vores programmer, eller finde ud af hvor tingene er går galt i vores programmer. GDB er forbavsende kraftfuld, men output og interaktion med det kan være en lille smule kryptisk. Det er normalt en kommandolinje værktøj, og det kan kaste en masse beskeder på dig. Og det kan slags svært at parse præcis, hvad der foregår. Heldigvis har vi taget skridt at løse dette problem for dig som du arbejder gennem CS50. Hvis du ikke bruger den grafiske debugger, som min kollega Dan Armandarse har talt helt lidt om i en video, der bør være herovre lige nu, skal du muligvis at bruge disse kommandolinjen redskaber til at arbejde med GDB. Hvis du arbejder i CS50 IDE, behøver du ikke at gøre dette. Men hvis du ikke er arbejder i CS50 IDE, måske ved hjælp af en version af CS50 Appliance, eller en anden Linux-operativsystem Systemet med GDB installeret på den, du måske nødt til at bruge disse kommandolinje værktøjer. 

Og da du måske nødt til at gøre det, er det nyttige bare at forstå, hvordan GDB værker fra kommandolinjen. Men igen, hvis du er ved hjælp af CS50 IDE, du kan bruge den grafiske debugger der er indbygget i IDE. Så for at få tingene i gang med GDB, at starte debugging processen af ​​en bestemt program, alt hvad du behøver gøre er skriv GDB følges ved navn programmet. Så for eksempel, hvis dit program er hej, ville du skriver GDB hej. 

Når du gør det, er du nødt at trække op GDB miljø. Din prompt vil ændre sig, og stedet for at være, hvad det normalt er, når du skriver ting på kommandoen line-- ls, cd-- alle dine typiske Linux kommandoer, dit hurtige vil skifte til, formentlig, noget ligesom parenteser GDB parentes. Det er din nye GDB prompt, fordi du er inde GDB miljø. Når du er inde i dette miljø, Der er to store kommandoer at du sandsynligvis vil bruge i følgende rækkefølge. 

Den første er b, som er en forkortelse for pause. Og efter du skriver b, du typisk skrive navnet på en funktion, eller hvis du tilfældigvis kender omkring hvad linjenummer dit program er begyndt at opføre sig lidt underligt, du kan skrive en linje nummer der. Hvad b, eller pause, gør er det giver dit program at køre indtil et vist punkt, nemlig navnet på funktionen som du angiver eller linjen nummer, som du angiver. 

Og på det tidspunkt, det vil fryse udførelse. Dette er en virkelig god ting, fordi når udførelsen har været frosset, du kan begynde at meget langsomt gå gennem dit program. Typisk hvis du har været at køre dine programmer, de er temmelig kort. Normalt, du skriver dot skråstreg uanset navnet på dit program, tryk på Enter, og før du kan blinke, din Programmet er allerede færdig. Det er egentlig ikke en masse tid til at prøve og finde ud af hvad der går galt. Så det virkelig at være i stand til at bremse tingene ned ved at sætte en pause punkt med b, og derefter træde ind. 

Så når du har indstillet din pause punkt, kan du køre programmet. Og hvis du har nogen kommandolinjeargumenter, du angiver dem her, ikke når du skriver GDB dit program navn. Du angiver alle kommandolinjen argumenter ved at tage r, eller løbe, og derefter hvad kommandolinjeargumenter du har brug for inde i dit program. Der er en række andre virkelig vigtige og nyttige kommandoer indersiden af ​​BNP miljøet. Så lad mig lige hurtigt gå over nogle af dem. 

Den første er n, som er en forkortelse for næste, og du kan skrive næste i stedet for n, begge ville arbejde. Og det er netop den stenografi. Og som du sikkert allerede har fået vant til, at kunne skrive ting kortere er generelt bedre. Og hvad det vil gøre, er at det vil træde frem en blok af kode. Så det vil bevæge sig fremad indtil et funktionskald. Og derefter i stedet for dykning i denne funktion og går gennem alle, der fungerer kode, vil det blot har den funktion. 

Funktionen vil blive kaldt. Det vil gøre, hvad dens arbejde er. Det vil returnere en værdi til den funktion, der kaldte det. Og så vil du gå videre til næste linje af denne kaldende funktion. Hvis du ønsker at træde indersiden af ​​funktionen, i stedet for bare at have det udføre, især hvis du tror, ​​at problemet kunne ligge inde i denne funktion, man kunne selvfølgelig indstille en pause peger indersiden af ​​denne funktion. Eller hvis du allerede kører, kan du bruge s til at træde frem én linje kode. 

Så dette vil træde i og dykke ned i funktioner, i stedet for bare have den udføre og fortsætter i funktionen at du er i for fejlretning. Hvis du nogensinde ønsker at vide værdien af ​​en variabel, du kan skrive p, eller Udskriv, og derefter variabelnavnet. Og der vil printe ud til dig, indersiden af ​​GDB miljø, navnet på den variable, der du-- undskylde mig-- værdien af ​​variablen at du har navngivet. Hvis du ønsker at vide værdien af ​​hver lokal variabel tilgængelige hvorfra du i øjeblikket er i din program, kan du skrive info lokale. Det er meget hurtigere end skrive p og derefter uanset hvad, notering ud af alle de variabler, som du kender eksisterer. Du kan skrive info lokale, og det vil udskrive alt for dig. Næste op er bt, som er forkortelse for Back Trace. Nu generelt især tidligt i CS50, vil du ikke rigtig har lejlighed at bruge bt, eller Back Trace, fordi du ikke har funktioner at ringe til andre funktioner. 

Du har måske vigtigste opkald en funktion, men det er sandsynligvis det. Du behøver ikke at andre funktion ringer til en anden funktion, som kalder en anden funktion, og så videre. Men da dine programmer får mere kompleks, og især når du begynder at arbejde med rekursion, back spor kan være en rigtig nyttig måde at lade dig slags få nogle kontekst for hvor Jeg er i mit program. Så siger du har skrevet din kode, og du ved, at main kalder en funktion f, der kalder en funktion g, hvilket kræver en funktion h. Så vi har flere lag af rugende foregår her. 

Hvis du er inde i din GDB miljø, og du kender din indeni af H, men du glemmer om, hvad der fik dig til, hvor du are-- du kan skrive bt, eller ryg spor, og det vil udskrive h, g, f vigtigste, sammen med nogle andre oplysninger, som giver dig et fingerpeg om, at, OK vigtigste kaldes f, f kaldes g, g kaldet H, og det er hvor jeg i øjeblikket er i mit program. Så det kan være virkelig nyttige, især da den kryptiske-ness af GDB bliver lidt overvældende, at finde ud af præcis, hvor tingene er. Endelig, når dit program er færdig, eller når du er færdig debugging det og du ønsker at træde væk fra GDB miljø, det hjælper at vide, hvordan man får ud af det. Du kan skrive q eller Quit, at komme ud. Nu, før dagens video Jeg forberedt et fejlbehæftet program kaldet buggy1, som jeg kompileret fra en fil kaldet buggy1.c. Som man kunne forvente, er dette Programmet er i virkeligheden buggy. Noget går galt når jeg forsøger og køre den. Nu, desværre, jeg uforvarende slettet min buggy1.c fil, så for mig at finde ud af hvad der går galt med dette program, Jeg har tænkt mig at bruge GDB slags blindt, forsøger at navigere gennem dette program til finde ud af præcis hvad der går galt. Men ved hjælp af kun de værktøjer vi allerede har lært om, Vi kan temmelig meget figur ud af, præcis hvad det er. Så lad os gå over til CS50 IDE og få et kig. OK, så vi er her i min CS50 IDE miljø, og jeg vil zoome ind en lille smule så du kan se lidt mere. I mit terminalvindue, hvis jeg liste indholdet af min nuværende direktør med ls, vil vi se, at jeg har et par kildefiler her, herunder tidligere diskuteret buggy1. Hvad der præcist foregår, når Jeg prøver og køre buggy1. Jamen så lad os finde ud af. Jeg skriver dot skråstreg, buggy, og jeg ramte Enter. 

Segmentering fejl. Det er ikke godt. Hvis du husker, en segmentering fejl typisk opstår, når vi adgang til hukommelsen at vi ikke får lov til at røre ved. Vi har en eller anden måde nået uden for grænserne af, hvad programmet, compiler, har givet os. Og så allerede der er en fingerpeg til at holde i værktøjskassen når vi begynder debugging proces. Noget er gået lidt galt her. 

Okay, så lad os starte op GDB miljø og se om vi kan finde ud af hvad problemet er. Jeg har tænkt mig at rydde min skærm, og jeg har tænkt mig at skrive GDB igen, for at komme ind i GDB miljø, og navnet på det program at jeg ønsker at debug, buggy1. Vi får en lille besked, læsning symboler fra buggy1, gjort. Alt det betyder, er det trak sammen hele koden, og nu er det blevet indlæst i GDB, og det er klar til at gå. 

Nu, hvad ønsker jeg at gøre? Kan du huske, hvad den første skridt typisk er efter at jeg er inde i dette miljø? Forhåbentlig sagde du indstille et knækpunkt, fordi i virkeligheden det er, hvad jeg ønsker at gøre. Nu har jeg ikke den kildekoden til dette foran mig, hvilket sandsynligvis ikke den typiske brug tilfældet, ved den måde. Du sandsynligvis vil. Så det er godt. Men forudsat at du ikke gør det, hvad der er den ene funktion, som du kender findes i hver eneste C-program? Uanset hvor stor eller hvor kompliceret Det er denne funktion faktisk findes. Main, ikke? 

Så mangel alt andet, vi kan sætte en pause punkt ved main. Og igen, jeg kunne bare skrive bryde vigtigste, i stedet for b. Og hvis du er nysgerrig, hvis du nogensinde skrive en lang kommando og derefter indse, at du indtastet de forkerte ting, og du ønsker at slippe af alle som jeg lige gjorde, du kan tage kontrol U, som vil slette alt og bringe dig tilbage til begyndelsen af ​​markøren linjer. Meget hurtigere end bare holde nede slette eller slå den en masse gange i. 

Så vi vil sætte en pause punkt ved main. Og som du kan se, det siger vi har sætte en pause punkt fil buggy1.c, og tilsyneladende den første linje kode af vigtigste er linie syv. Igen, har vi ikke kildefilen her, men jeg vil antage, at det er fortæller mig sandheden. Og så, jeg prøver bare og køre programmet, r. Start af programmet. Okay, så dette budskab er lidt kryptisk. Men dybest set, hvad der er sker her, er det bare fortæller mig jeg har ramt min pause punkt, break point nummer 1. 

Og så, at linje kode, Ingen sådan fil eller mappe. Den eneste grund til at Jeg ser dette budskab er fordi jeg uforvarende slettet min buggy.c fil. Hvis min buggy1.c fil eksisterede i det aktuelle bibliotek, denne linje lige der ville faktisk fortælle mig, hvad den linje kode bogstaveligt læser. Desværre, jeg slettede det. Vi bliver nødt til at slags navigere gennem denne lidt mere blindt. 

OK, så lad os se, hvad ønsker jeg at gøre her? Nå, jeg vil gerne vide, hvad lokale variabler måske er tilgængelige for mig. Jeg er begyndt mit program. Lad os se, hvad der kunne være allerede initialiseret for os. Jeg skriver Info lokalbefolkningen, ingen lokale. Okay, så ikke give mig et ton af oplysninger. Jeg kunne prøve at udskrive en variabel, men jeg kender ikke nogen variabelnavne. Jeg kunne prøve en back spor, men jeg er inde i main, så jeg ved, jeg ikke har gjort en anden funktion opkald lige nu. 

Så ligner min eneste muligheder er at bruge n eller så og begynder at dykke i. Jeg har tænkt mig at bruge n. Så jeg skriver n. Åh min gosh, hvad der foregår her. Program, der modtages signaler, SIGSEGV segmentering skyld, og derefter en hel masse ting. Jeg er allerede overvældet. Tja, der er faktisk en meget at lære her. Så hvad siger det os? Hvad det fortæller os, er, dette program er ved at, men har endnu ikke, seg fejl. Og i særdeleshed, vil jeg at zoome ind endnu længere her, det handler om at seg fejl om noget, der hedder strcmp. 

Nu kan vi ikke har diskuteret denne funktion i vid udstrækning. Men det is-- fordi vi ikke kommer at tale om hver funktion, eksisterer i C standarden library-- men de er alle til rådighed for dig, især hvis du tager en se på reference.cs50.net. Og strcmp er en virkelig kraftfuld funktion, der eksisterer inde af string.h header fil, som er en header fil, der er dedikeret til funktioner at arbejdet med og manipulere strenge. 

Og i særdeleshed, hvad strcmp gør, er sammenligner værdierne af to strenge. Så jeg er ved at segmentering fejl på et kald til strcmp det ser ud. Jeg ramte n, og faktisk får jeg beskeden, Programmet afsluttes med signal SIGSEGV segmentering skyld. Så nu Jeg har faktisk seg afbrudt, og mit program har temmelig meget effektivt givet op. Dette er afslutningen af ​​programmet. Det brød ned, det styrtede ned. Så var ikke meget, men jeg faktisk gjorde lære en hel del fra denne lille oplevelse. Hvad har jeg lært? Nå, mit program går ned temmelig meget det samme. Mit program går ned på Et opkald til strcmp, men jeg har ikke nogen lokale variable i min programmet på det tidspunkt, det går ned. Så hvad streng, eller strygere, kunne jeg muligvis være at sammenligne. Hvis jeg ikke har nogen lokal variabler, kan du formode, at jeg have-- der måske er en global variabel, som kunne være sandt. 

Men generelt forekommer det ligesom jeg sammenligne til noget, der ikke eksisterer. Så lad os undersøge at en lidt længere. Så jeg har tænkt mig at rydde min skærm. Jeg har tænkt mig at holde op ud af det GDB miljø for et sekund. Og jeg tænker, OK, så der er ingen lokale variabler i mit program. Jeg spekulerer på, om måske jeg skulle passere i en streng som en kommandolinje argument. Så lad os bare prøve det ud. Jeg har ikke gjort det før. 

Lad os se, om måske hvis jeg køre dette program med en kommandolinje argument det virker. Huh, ingen segmentering fejl der. Det lige fortalt mig, at jeg regnede det ud. Så måske det er rettelsen her. Og ja, hvis jeg går tilbage og se på den faktiske kildekoden til buggy1.c, det virker som om, hvad jeg gør, er Jeg gør et opkald til strcmp uden kontrollere, om faktisk argv [1] findes. Dette er faktisk den kildekoden til buggy1.c. Så hvad jeg virkelig har brug for at gøre her for at lave mit program, antager jeg har den fil foran mig, er at blot tilføje en check til at gøre sikker på, at argc er lig med 2. Så dette eksempel igen, som jeg sagde, er en lille smule konstruerede, ikke? Du normalt ikke kommer til at uheld sletter din kildekode og derefter nødt til at prøve og debug af programmet. Men forhåbentlig, det gav du en illustration af den slags ting, der kunne du tænke som du fejlfindingen af ​​programmet. 

Hvad er tingenes tilstand her? Hvilke variabler gør jeg har adgang til mig? Hvor præcist er mit program styrter ned, på hvilken linje, på hvilke opkald til hvilken funktion? Hvilken slags spor betyder det giver mig? Og det er præcis den slags tankegang, at du skal komme ind, når du er tænker debugging dine programmer. 

Jeg er Doug Lloyd. Det er CS50.