DOUG LLOYD: Oké GDB. Wat is het precies? Dus GDB, wat staat voor de GNU debugger, is echt een geweldig instrument dat we kunnen te gebruiken om ons te helpen debuggen onze programma's, of uit te vinden waar de dingen zijn fout gaat in onze programma's. GDB is ongelooflijk krachtig, maar de output en interactie ermee kan een beetje cryptisch. Het is meestal een command-line tool, en het kan veel berichten naar je gooien. En het kan een beetje moeilijk om ontleden precies wat er aan de hand. Gelukkig hebben we maatregelen genomen om dit probleem op te lossen voor u terwijl u werkt door middel van CS50. Als u geen gebruik maakt van de grafische debugger, die mijn collega Dan Armandarse heeft vrij gesproken een beetje over in een video, die een moet hier worden op dit moment, zou je nodig hebt deze command line te gebruiken gereedschappen om te werken met GDB. Als je werkt in de CS50 IDE, heb je niet nodig om dit te doen. Maar als je niet werken in de CS50 IDE, misschien een versie van CS50 Appliance of een andere Linux operating GDB systeem geïnstalleerd is, u kan nodig zijn om te gebruiken Deze command line tools. 

En omdat je misschien om dat te doen, het is handig gewoon om te begrijpen hoe GDB werkt vanaf de opdrachtregel. Maar nogmaals, als je met behulp van de CS50 IDE, u kan de grafische debugger gebruiken die is ingebouwd in de IDE. Dus dingen gaan met te krijgen GDB, de debug starten Werkwijze van een bepaalde programma, moet alles wat je doet wordt het type GDB gevolgd Door de programmanaam. Dus bijvoorbeeld, als uw programma hallo, je zou GDB hallo typen. 

Als je dat doet, je gaat te trekken van het GDB milieu. Je prompt zal veranderen, en in plaats van wat gewoonlijk is wanneer je dingen typt op de opdrachtregel line-- ls, CD-- al uw typische Linux-commando's, je prompt zal veranderen, waarschijnlijk iets zoals haakjes GDB haakjes. Dat is uw nieuwe GDB prompt, omdat u bent in de GDB milieu. Eenmaal binnen van die omgeving, er zijn twee grote opdrachten die je waarschijnlijk zult gebruiken in deze volgorde. 

De eerste is b, waarin is de afkorting voor pauze. En na u, u doorgaans typt b typt u de naam van een functie, of als je toevallig weten rond wat lijnnummer het programma begint zich te gedragen een beetje raar, U kunt een lijn typen nummer daar ook. Wat b, of breken, doet is het mogelijk het programma te lopen tot een bepaald punt, namelijk de naam van de functie die u opgeeft of de lijn nummer dat u opgeeft. 

En op dat punt, zal de uitvoering te bevriezen. Dit is echt een goede zaak, want zodra uitvoering is bevroren, kun je heel langzaam beginnen te stap door het programma. Typisch, als je bent geweest running uw programma's, ze zijn vrij kort. Meestal u dot slash typt wat de naam van het programma wordt, druk op Enter, en voordat u kunt knipperen, uw programma is al klaar. Het is niet echt veel tijd om te proberen en erachter te komen wat er mis gaat. Dus het echt in staat zijn om dingen te vertragen door het instellen van een break point met b, en dan stapt in. 

Dan zodra u uw vakantie hebt ingesteld punt, kunt u het programma uitvoert. En als u hebt command line argumenten, je ze hier opgeven, niet wanneer je typt GDB programma naam. U specificeert de opdrachtregel argumenten door het nemen van r, of lopen, en dan argumenten wat command line je nodig hebt binnenkant van uw programma. Er zijn een aantal andere echt belangrijke en nuttige commando binnenkant van het BBP milieu. Dus laat me gewoon snel gaan over een aantal van hen. 

De eerste is n, die kort voor de volgende, en je kunt typen naast in plaats van n, beide zou werken. En het is gewoon de afkorting. En zoals je hebt waarschijnlijk al gekregen gebruikt, in staat om dingen te typen korter is algemeen beter. En wat het zal doen, is het zal stap voor een blok van code. Dus het zal vooruit totdat er een functie aan te roepen. En dan in plaats van duiken in die functie en gaan door al die functies code, zal het alleen maar hebben de functie. 

De functie zal worden genoemd. Het zal doen wat haar werk is. Het zal een waarde terugkeren de functie die het genoemd. En dan zul je op het bewegen volgende regel van die roeping functie. Als u wilt stap binnenzijde van de functie, in plaats van alleen het hebben het uit te voeren, met name als je denkt dat het probleem kunnen binnen van die functie liggen, je kan natuurlijk, set een break punt binnenzijde van die functie. Of als u al gebruik maakt, kunt u s gebruiken om naar een regel code stap. 

Zo zal deze stap in en duik in functies, in plaats van alleen maar de uit te voeren en verder op de functie dat je in voor het debuggen. Als je ooit wilt weten de waarde van een variabele, u kunt typen p, of Afdrukken, en dan de naam van de variabele. En dat zal uitprinten voor u, binnenzijde van de GDB milieu, de naam van de variabele, die je-- excuus mij-- de waarde van de variabele die je hebt genoemd. Als u wilt dat de waarden van elke weten lokale variabele bereikbaar vanwaar u op dit moment in programma, typt u info locals. Het is een stuk sneller dan typen p en dan wat dan ook, listing alle van de variabelen die u weet bestaan. U kunt typen info locals, en het zal er alles uit te printen voor u. Next up is BT, dat is kort voor Back Trace. Nu algemeen met name in het begin van CS50, je zult niet echt gelegenheid BT, of Back Trace gebruiken, omdat je niet met functies dat noemen andere functies. 

Je zou een belangrijke oproep hebben functie, maar dat is waarschijnlijk het. Je hoeft niet dat andere functie een andere functie, roepen die roept andere functie, enzovoorts. Maar als uw programma's krijgen meer complex, met name wanneer je begint te werken met recursie, rug spoor kan een heel nuttige manier om u te laten zijn soort nog wat context want waar Ik ben in mijn programma. Dus zeggen dat je hebt je code geschreven, en je weet dat de belangrijkste noemt een functie f, waarbij een functieaanroepen G, die een functie h noemt. Dus we hebben meerdere lagen nestelende hier aan de hand. 

Als je binnen bent van GDB uw omgeving, en je weet dat je van binnen van h, maar je vergeet over wat je moet waar u zijn-- u kunt typen bt of rug spoor, en het zal uitprinten h, g, f belangrijkste, naast enkele andere informatie, die geeft u een aanwijzing dat, OK belangrijkste genaamd f, f genoemd g, g zogenaamde h, en dat is waar ik momenteel ben in mijn programma. Dus het kan echt nuttig, vooral omdat de cryptische-heid van GDB wordt een beetje overweldigend, om precies te weten waar dingen zijn. Tot slot, wanneer het programma wordt gedaan, of als je klaar bent debuggen en je wilt om weg te stappen de GDB milieu het helpt om te weten hoe om uit te halen. U kunt typen q, of Stoppen, om eruit te komen. Nu, voordat video van vandaag Ik een buggy programma voorbereid genaamd buggy1, die ik samengesteld uit een bestand bekend als buggy1.c. Zoals je zou verwachten, dit programma in feite buggy. Er iets mis gaat wanneer ik probeer en voer het uit. Nu, helaas, ik per ongeluk verwijderde mijn buggy1.c bestand, dus om voor mij om erachter te komen Wat is er mis gaat met dit programma, Ik ga moeten gebruiken GDB soort blind, proberen om te navigeren door middel van dit programma erachter te komen wat er mis gaat. Maar met alleen de gereedschappen we hebben al geleerd over, kunnen we vrij veel figuur precies wat het is. Dus laten we het hoofd naar CS50 IDE en een kijkje nemen. OK, dus we zijn hier in mijn CS50 IDE milieu, en ik zal in een klein beetje te zoomen dus je kan een beetje meer te zien. In mijn terminal venster, als ik de lijst de inhoud van mijn huidige directeur met ls, zullen we zien dat ik hebben een paar van de bronbestanden Hier, inclusief eerder besproken buggy1. Wat er precies gaat aan wanneer Ik probeer en lopen buggy1. Nou laten we eens kijken. Ik typ dot slash, buggy, en ik druk op Enter. 

Segmentatie fouten. Dat is niet goed. Misschien herinner je je, een segmentation fault doorgaans ontstaat wanneer we toegang tot het geheugen dat we hem niet mogen aanraken. We hebben een of andere manier bereikt buiten de grenzen van wat het programma, de compiler, heeft ons. En zo al dat is een aanwijzing in de toolbox te houden als we beginnen het debugging proces. Iets is gegaan hier een beetje verkeerd. 

Oké, dus laten we beginnen de GDB milieu en kijken of we kunnen achterhalen wat precies het probleem is. Ik ga mijn scherm te wissen, en ik ga om te typen GDB nogmaals, om het GDB milieu terechtkomen, en de naam van het programma dat ik wil debuggen, buggy1. We krijgen een klein bericht, lezen symbolen uit buggy1, gedaan. Alle dat betekent is dat getrokken samen alle van de code, en nu is het al in geladen GDB, en het is klaar om te gaan. 

Nu, wat wil ik doen? Herinnert u zich wat de eerste stap typisch nadat ik ben binnenkant van deze omgeving? Hopelijk zei dat je instellen een breekpunt, want in feite dat is wat ik wil doen. Nu, ik heb niet de broncode voor deze voor me, dat is waarschijnlijk niet de typische use case, door de manier waarop. Je hebt waarschijnlijk wel. Dus dat is goed. Maar ervan uitgaande dat je dat niet doet, wat is de ene functie die u weet bestaat in ieder C-programma? Het maakt niet uit hoe groot of hoe ingewikkeld is deze functie zeker bestaat. Belangrijkste, toch? 

Zo niet alles, we kunnen set een breekpunt in de belangrijkste. En nogmaals, kon ik typ breken belangrijkste, in plaats van b. En als je nieuwsgierig bent, als je ooit uittypen een lange opdracht en dan beseffen dat je getypt de verkeerde dingen, en u wilt zich te ontdoen alle zoals ik net deed, U kunt controle nemen, dat zal verwijder alles en brengen u terug aan het begin van de cursorlijnen. Een stuk sneller dan alleen houdt u de verwijderen, of slaan het een stelletje keer voorbij. 

Dus we een break point ingesteld op hoofd. En zoals je kunt zien, het zegt we hebben set een breekpunt in file buggy1.c, en blijkbaar de eerste lijn van de code van de belangrijkste lijn is zeven. Nogmaals, we hebben niet het bronbestand hier maar ik ga ervan uit dat het vertel me de waarheid. En dan, ik probeer gewoon en start het programma, r. Beginnend programma. Oké, dus dit bericht is een beetje cryptisch. Maar eigenlijk wat is hier gebeurt is het is gewoon me te vertellen Ik heb mijn pauze hit punt, breekpunt nummer 1. 

En dan, dat regel code, Bestand of map bestaat niet. De enige reden dat Ik zie dat bericht is omdat ik per ongeluk verwijderde mijn buggy.c bestand. Als mijn buggy1.c dossier bestond in de huidige directory, die lijn daar zou eigenlijk mij vertellen wat de regel code letterlijk leest. Helaas, ik verwijderde het. We zullen moeten soort navigeren door deze een beetje meer blind. 

OK, dus laten we eens kijken, wat wil ik hier te doen? Nou, ik zou graag willen weten wat de lokale variabelen misschien zijn beschikbaar voor mij. Ik heb mijn programma begon. Laten we eens kijken wat er zou kunnen zijn al geïnitialiseerd voor ons. Ik typ Info lokale bevolking, geen locals. Oké, zodat niet geef me een heleboel informatie. Ik zou kunnen proberen en afdrukken van een variabele, maar ik ken geen namen van variabelen. Ik kon een spoor terug te proberen, maar ik ben binnenkant van de belangrijkste, dus ik weet dat ik niet gemaakt een andere functie oproep nu. 

Zo ziet eruit als mijn enige opties zijn te gebruiken n of zo en beginnen om te duiken in. Ik ga gebruiken n. Dus ik typ n. Oh mijn god, wat is hier aan de hand. Programma ontvangen signalen, SIGSEGV segmentation fault, en dan een hele hoop dingen. Ik ben al overweldigd. Nou, er is eigenlijk een hier veel te leren. Dus wat heeft dit ons vertellen? Wat het ons vertelt is, is dit programma gaat, maar heeft nog niet, seg fout. En in het bijzonder, ik ga in nog verder hier om in te zoomen, het is op het punt om de schuld SEG over iets genaamd strcmp. 

Nu kunnen we niet hebben besproken Deze functie uitgebreid. Maar het is-- want we gaan niet om te praten over elke functie bestaat in de C standaard library-- maar ze zijn allemaal voor u beschikbaar, vooral als je een te nemen kijk naar reference.cs50.net. En strcmp is een echt krachtig functie die binnenin bestaat van de string.h header file, die een header bestand dat is gewijd aan functies die werken met en manipuleren van strings. 

En in het bijzonder, wat doet is strcmp vergelijkt de waarden van twee snaren. Dus ik ben op het punt om de schuld segmentatie op een oproep tot strcmp het lijkt. Ik raakte n, en in feite krijg ik het bericht, programma beëindigd met signaal SIGSEGV segmentatie fout. Dus nu Ik heb eigenlijk seg verweten, en mijn programma heeft vrij veel effectiever opgegeven. Dit is het einde van het programma. Het brak, het neerstortte. Dus was niet veel, maar ik eigenlijk deed leren nogal een beetje van deze weinig ervaring. Wat heb ik geleerd? Nou, mijn programma crasht vrijwel onmiddellijk. Mijn programma crasht op Een oproep aan strcmp, maar ik geen enkele lokale variabelen niet in mijn programma op het moment dat het crasht. Dus wat string of strings, zou ik misschien te vergelijken. Als ik geen lokale hebben variabelen, zou je vermoeden dat ik daar have-- misschien is een globale variabele, die waar kan zijn. 

Maar over het algemeen lijkt alsof ik het vergelijken iets dat niet bestaat. Dus laten we onderzoeken die een beetje verder. Dus ik ga mijn scherm te wissen. Ik ga om te stoppen uit de GDB omgeving voor een tweede. En ik ben denken, OK, dus er is geen lokale variabelen in mijn programma. Ik vraag me af of misschien ben ik verondersteld om te passeren in een string als een command line argument. Dus laten we dit uit te testen. Ik heb dit niet eerder gedaan. 

Eens kijken of misschien als ik dit programma uit te voeren met een command line argument het werkt. Huh, geen segmentation fault daar. Het zei me alleen dat ik dacht dat het uit. Dus misschien is dat hier de oplossing. En inderdaad, als ik ga terug en kijk naar de werkelijke broncode voor buggy1.c, het lijkt alsof wat ik doe is Ik ben het maken van een oproep aan strcmp zonder nagaan of inderdaad argv [1] bestaat. Dit is eigenlijk de broncode voor buggy1.c. Dus wat ik echt nodig om doe hier mijn programma vast te stellen, veronderstelling dat ik de file voor me, is om voeg een cheque te maken zorgen dat argc gelijk is aan 2. Dus dit voorbeeld, opnieuw, zoals ik al zei, is een beetje gekunsteld, toch? Je over het algemeen niet van plan om per ongeluk uw broncode verwijderen en dan te proberen en debuggen van het programma. Maar hopelijk, het gaf u een illustratie van de dingen die je zou kunnen denken over als je het debuggen van uw programma. 

Wat is de stand van zaken hier? Welke variabelen kan ik moeten toegankelijk zijn voor me? Waar precies is mijn programma crashen, wat lijn, over wat oproep om welke functie? Wat voor aanwijzingen heeft dat mij? En dat is precies de soort mentaliteit dat je moet krijgen in als je na te denken over het debuggen van uw programma's. 

Ik ben Doug Lloyd. Dit is CS50.