1
00:00:00,000 --> 00:00:02,000
[Powered by Google Translate] [Valgrind]

2
00:00:02,000 --> 00:00:05,000
[Nate Hardison, Harvard University]

3
00:00:05,000 --> 00:00:07,000
Dit is CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
Enkele van de meest moeilijke bugs in C-programma's

5
00:00:10,000 --> 00:00:13,000
komen uit het wanbeheer van het geheugen.

6
00:00:13,000 --> 00:00:15,000
Er zijn een groot aantal manieren om dingen te verknallen,

7
00:00:15,000 --> 00:00:17,000
inclusief de toewijzing van de verkeerde hoeveelheid geheugen,

8
00:00:17,000 --> 00:00:20,000
vergeten om variabelen te initialiseren,

9
00:00:20,000 --> 00:00:23,000
schrijven voor of na het einde van een buffer,

10
00:00:23,000 --> 00:00:25,000
en het vrijmaken van de herinnering te meerdere keren.

11
00:00:25,000 --> 00:00:28,000
De symptomen variëren van intermitterende crashes

12
00:00:28,000 --> 00:00:30,000
op mysterieuze wijze overschreven waarden,

13
00:00:30,000 --> 00:00:34,000
vaak op plaatsen en tijden ver verwijderd van de oorspronkelijke fout.

14
00:00:34,000 --> 00:00:37,000
Het opsporen van de waargenomen probleem terug naar de onderliggende oorzaak

15
00:00:37,000 --> 00:00:39,000
kan lastig zijn,

16
00:00:39,000 --> 00:00:42,000
maar gelukkig is er een handige programma genaamd Valgrind

17
00:00:42,000 --> 00:00:44,000
dat kan veel doen om te helpen.

18
00:00:44,000 --> 00:00:47,000
>> U voert een programma onder Valgrind in staat te stellen

19
00:00:47,000 --> 00:00:50,000
uitgebreide controle van heap geheugen toewijzingen en toegangen.

20
00:00:50,000 --> 00:00:53,000
Wanneer Valgrind een probleem vindt, het geeft je directe,

21
00:00:53,000 --> 00:00:56,000
directe informatie die u toelaat om

22
00:00:56,000 --> 00:00:58,000
gemakkelijker te vinden en het probleem oplossen.

23
00:00:58,000 --> 00:01:01,000
Valgrind ook rapporten over minder dodelijke geheugenproblemen,

24
00:01:01,000 --> 00:01:04,000
zoals geheugenlekken, toewijzen heap geheugen,

25
00:01:04,000 --> 00:01:07,000
en vergeten om het te bevrijden.

26
00:01:07,000 --> 00:01:10,000
Net als onze compiler, Clang, in onze debugger, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind is vrije software, en het is geïnstalleerd op het apparaat.

28
00:01:14,000 --> 00:01:16,000
Valgrind draait op uw binaire, uitvoerbare,

29
00:01:16,000 --> 00:01:20,000
niet uw. c of. h broncode-bestanden,

30
00:01:20,000 --> 00:01:23,000
dus zorg ervoor dat u een up-to-date kopie van uw programma samengesteld

31
00:01:23,000 --> 00:01:25,000
met behulp van Clang Of Bod.

32
00:01:25,000 --> 00:01:28,000
Dan kan u het programma onder Valgrind worden

33
00:01:28,000 --> 00:01:32,000
zo eenvoudig als gewoon door aan de standaard programma-opdracht met het woord Valgrind,

34
00:01:32,000 --> 00:01:35,000
die begint op Valgrind en loopt het programma binnenkant van het.

35
00:01:35,000 --> 00:01:38,000
Bij het starten van, Valgrind doet een aantal complexe

36
00:01:38,000 --> 00:01:41,000
jiggering naar het uitvoerbare configureren voor het geheugen controles,

37
00:01:41,000 --> 00:01:44,000
dus het kan wel een beetje te krijgen up and running.

38
00:01:44,000 --> 00:01:48,000
Het programma zal dan normaal uitgevoerd, zij het veel langzamer,

39
00:01:48,000 --> 00:01:52,000
en wanneer het klaar is, zal Valgrind drukt u een overzicht van het geheugen gebruik.

40
00:01:52,000 --> 00:01:58,000
Als alles goed gaat, zal het er ongeveer zo uitzien:

41
00:01:58,000 --> 00:02:01,000
In dit geval. / Clean_program

42
00:02:01,000 --> 00:02:04,000
is het pad naar het programma dat ik wil uitvoeren.

43
00:02:04,000 --> 00:02:06,000
En terwijl deze neemt geen argumenten,

44
00:02:06,000 --> 00:02:09,000
als dat wel Ik zou gewoon overstag ze op aan het einde van de opdracht zoals gewoonlijk.

45
00:02:09,000 --> 00:02:12,000
Clean-programma is gewoon een dom klein programma die ik heb gemaakt

46
00:02:12,000 --> 00:02:15,000
dat wijst ruimte voor een blok ints op de heap,

47
00:02:15,000 --> 00:02:19,000
er wat waarden binnenkant van hen, en bevrijdt het hele blok.

48
00:02:19,000 --> 00:02:23,000
Dit is wat je filmt voor, geen fouten en geen lekken.

49
00:02:23,000 --> 00:02:27,000
>> Een andere belangrijke maatstaf is het totaal aantal toegewezen bytes.

50
00:02:27,000 --> 00:02:32,000
Afhankelijk van het programma, als uw toewijzingen zijn in de megabytes of hoger,

51
00:02:32,000 --> 00:02:34,000
ben je waarschijnlijk iets verkeerd.

52
00:02:34,000 --> 00:02:37,000
Bent u onnodig opslaan van duplicaten?

53
00:02:37,000 --> 00:02:40,000
Gebruikt u de hoop voor de opslag, wanneer het beter zou zijn om de stapel te gebruiken?

54
00:02:40,000 --> 00:02:43,000
Dus kan geheugenfouten echt kwaad.

55
00:02:43,000 --> 00:02:46,000
Hoe meer openlijke die leiden tot spectaculaire crashes,

56
00:02:46,000 --> 00:02:49,000
maar zelfs dan kan het nog steeds moeilijk te lokaliseren

57
00:02:49,000 --> 00:02:51,000
wat precies leidde tot de crash.

58
00:02:51,000 --> 00:02:54,000
Meer verraderlijk, een programma met een geheugen fout

59
00:02:54,000 --> 00:02:56,000
kan nog steeds netjes samen te stellen

60
00:02:56,000 --> 00:02:58,000
en kan nog steeds lijken correct te laten werken

61
00:02:58,000 --> 00:03:01,000
omdat je erin geslaagd om je geluk meeste van de tijd.

62
00:03:01,000 --> 00:03:04,000
Na een aantal 'succesvolle resultaten, "

63
00:03:04,000 --> 00:03:07,000
kun je net denken dat een crash is een toevalstreffer van de computer,

64
00:03:07,000 --> 00:03:10,000
maar de computer is nooit verkeerd.

65
00:03:10,000 --> 00:03:13,000
>> Running Valgrind kan u helpen bij het opsporen van de oorzaak van de zichtbare geheugenfouten

66
00:03:13,000 --> 00:03:18,000
alsmede vinden op de loer fouten die je nog niet eens weten.

67
00:03:18,000 --> 00:03:22,000
Elke keer Valgrind een probleem detecteert, drukt het informatie over wat het waargenomen.

68
00:03:22,000 --> 00:03:24,000
Elk item is vrij kort -

69
00:03:24,000 --> 00:03:27,000
de bron lijn van de gewraakte instructie, wat het probleem is,

70
00:03:27,000 --> 00:03:30,000
en een beetje info over de betrokken geheugen -

71
00:03:30,000 --> 00:03:34,000
maar vaak is het genoeg informatie om je aandacht te richten op de juiste plaats.

72
00:03:34,000 --> 00:03:37,000
Hier is een voorbeeld van Valgrind draaien op een buggy programma

73
00:03:37,000 --> 00:03:40,000
dat doet een ongeldige lezen van heap geheugen.

74
00:03:40,000 --> 00:03:49,000
Wij zien geen fouten of waarschuwingen in compilaties.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, de fout samenvatting zegt dat er twee fouten -

76
00:03:53,000 --> 00:03:56,000
twee ongeldige maal gelezen van maat 4 - bytes, dat is.

77
00:03:56,000 --> 00:04:01,000
Beide slecht leest voorgedaan in de belangrijkste functie van invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
de eerste op lijn 16 en de tweede op de lijn 19.

79
00:04:04,000 --> 00:04:06,000
Laten we eens kijken naar de code.

80
00:04:06,000 --> 00:04:11,000
Het lijkt erop dat de eerste oproep tot printf probeert om een ​​int lezen voorbij het einde van ons geheugen blok.

81
00:04:11,000 --> 00:04:13,000
Als we terugkijken aan de uitgang van Valgrind's,

82
00:04:13,000 --> 00:04:16,000
zien we dat Valgrind ons verteld precies dat.

83
00:04:16,000 --> 00:04:19,000
Het adres dat we proberen te lezen begint 0 bytes

84
00:04:19,000 --> 00:04:22,000
voorbij het einde van het blok van 16 bytes omvang -

85
00:04:22,000 --> 00:04:25,000
vier 32-bit ints dat we toegewezen.

86
00:04:25,000 --> 00:04:29,000
Dat wil zeggen, het adres dat we probeerden om te lezen begint direct aan het einde van onze straat,

87
00:04:29,000 --> 00:04:32,000
net zoals we zien in onze slechte printf aan te roepen.

88
00:04:32,000 --> 00:04:36,000
Nu, zou ongeldig leest lijkt niet zo groot van een deal,

89
00:04:36,000 --> 00:04:39,000
maar als u gebruik maakt van die gegevens aan de stroom van uw programma te controleren -

90
00:04:39,000 --> 00:04:42,000
bijvoorbeeld als onderdeel van een if-statement of lus -

91
00:04:42,000 --> 00:04:45,000
dan dingen kan stil gaan slecht.

92
00:04:45,000 --> 00:04:47,000
Kijk hoe kan ik het invalid_read programma uit te voeren

93
00:04:47,000 --> 00:04:50,000
en niets uit de gewone gebeurt.

94
00:04:50,000 --> 00:04:52,000
Scary, he?

95
00:04:52,000 --> 00:04:56,000
>> Laten we nu eens kijken naar enkele meer soorten fouten die zich kunnen voordoen in uw code,

96
00:04:56,000 --> 00:04:59,000
en we zullen zien hoe Valgrind detecteert.

97
00:04:59,000 --> 00:05:01,000
We zagen een voorbeeld van een invalid_read,

98
00:05:01,000 --> 00:05:04,000
dus laten we nu eens kijken een invalid_write.

99
00:05:04,000 --> 00:05:09,000
Nogmaals, geen fouten of waarschuwingen in compilaties.

100
00:05:09,000 --> 00:05:12,000
Oke, Valgrind zegt dat er twee fouten in dit programma -

101
00:05:12,000 --> 00:05:15,000
en invalid_write en een invalid_read.

102
00:05:15,000 --> 00:05:18,000
Laten we eens kijken deze code.

103
00:05:18,000 --> 00:05:21,000
Het lijkt erop dat we hebben een exemplaar van de klassieke strlen plus een bug.

104
00:05:21,000 --> 00:05:24,000
De code is niet malloc een extra byte van de ruimte

105
00:05:24,000 --> 00:05:26,000
voor het / 0 karakter,

106
00:05:26,000 --> 00:05:30,000
dus als str kopie ging om het te schrijven op ssubstrlen "CS50 rocks!"

107
00:05:30,000 --> 00:05:33,000
schreef 1 byte voorbij het einde van onze straat.

108
00:05:33,000 --> 00:05:36,000
De invalid_read komt wanneer we onze oproep om printf.

109
00:05:36,000 --> 00:05:40,000
Printf eindigt het lezen van ongeldig geheugen tijdens het lezen van de / 0 karakter

110
00:05:40,000 --> 00:05:43,000
omdat wij naar het einde van deze E snaar het afdrukken.

111
00:05:43,000 --> 00:05:45,000
Maar niets van dit alles ontsnapt Valgrind.

112
00:05:45,000 --> 00:05:48,000
We zien dat het de invalid_write gevangen als onderdeel van de str kopie

113
00:05:48,000 --> 00:05:51,000
on line 11 van de belangrijkste, en de invalid_read maakt deel uit van printf.

114
00:05:51,000 --> 00:05:54,000
Rock op, Valgrind.

115
00:05:54,000 --> 00:05:57,000
Nogmaals, kan dit niet als een groot probleem.

116
00:05:57,000 --> 00:06:00,000
We kunt dit programma over en buiten Valgrind

117
00:06:00,000 --> 00:06:03,000
en zie geen fout symptomen.

118
00:06:03,000 --> 00:06:06,000
>> Maar laten we eens kijken naar een lichte variatie van dit te zien

119
00:06:06,000 --> 00:06:09,000
hoe de dingen kunnen echt slecht.

120
00:06:09,000 --> 00:06:14,000
Dus, verleend, zijn we misbruik maken van dingen meer dan alleen maar een beetje in deze code.

121
00:06:14,000 --> 00:06:17,000
We zijn alleen toewijzing van ruimte op de heap voor twee strings

122
00:06:17,000 --> 00:06:19,000
de lengte van CS50 rotsen,

123
00:06:19,000 --> 00:06:22,000
dit keer, het onthouden van de / 0 karakter.

124
00:06:22,000 --> 00:06:25,000
Maar dan gooien we in een super-lange string in het geheugen blok

125
00:06:25,000 --> 00:06:27,000
dat wijst naar S.

126
00:06:27,000 --> 00:06:30,000
Welk effect heeft dat op het geheugenblok dat T verwijst naar?

127
00:06:30,000 --> 00:06:34,000
Nou, als T verwijst naar het geheugen dat is gewoon naast S,

128
00:06:34,000 --> 00:06:37,000
komende net na het,

129
00:06:37,000 --> 00:06:39,000
dan zouden we hebben geschreven over een deel van T.

130
00:06:39,000 --> 00:06:41,000
Laten we deze code uitvoert.

131
00:06:41,000 --> 00:06:43,000
Kijk naar wat er gebeurd is.

132
00:06:43,000 --> 00:06:47,000
De snaren hebben we opgeslagen in onze hoop blokkeert zowel leek te hebben afgedrukt op de juiste wijze.

133
00:06:47,000 --> 00:06:49,000
Niets lijkt verkeerd.

134
00:06:49,000 --> 00:06:52,000
Maar laten we terug gaan naar onze code en

135
00:06:52,000 --> 00:06:55,000
commentaar van de regel waar we kopiëren CS50 rotsen

136
00:06:55,000 --> 00:06:59,000
in de tweede geheugenblok, wordt gewezen door t.

137
00:06:59,000 --> 00:07:02,000
Nu, als we deze code uitvoeren moeten we

138
00:07:02,000 --> 00:07:06,000
alleen de inhoud van het eerste geheugen blok uit te printen.

139
00:07:06,000 --> 00:07:09,000
Whoa, ook al hebben we niet str kopie

140
00:07:09,000 --> 00:07:12,000
alle tekens in de tweede hoop blok, de een wordt gewezen door T,

141
00:07:12,000 --> 00:07:15,000
krijgen we een uitdraai.

142
00:07:15,000 --> 00:07:18,000
Inderdaad, de string die we gevuld in onze eerste blok

143
00:07:18,000 --> 00:07:21,000
overschreed het eerste blok en in het tweede blok,

144
00:07:21,000 --> 00:07:23,000
het maken van alles normaal lijkt.

145
00:07:23,000 --> 00:07:26,000
Valgrind, hoewel, vertelt het ware verhaal.

146
00:07:26,000 --> 00:07:28,000
Daar gaan we dan.

147
00:07:28,000 --> 00:07:32,000
Al die ongeldige leest en schrijft.

148
00:07:32,000 --> 00:07:36,000
>> Laten we eens kijken naar een voorbeeld van een ander soort fout.

149
00:07:36,000 --> 00:07:39,000
Hier hebben we iets doen nogal ongelukkig.

150
00:07:39,000 --> 00:07:41,000
We grijpen ruimte voor een int op de heap,

151
00:07:41,000 --> 00:07:45,000
en we initialiseren van een int pointer - p - om te wijzen op die ruimte.

152
00:07:45,000 --> 00:07:48,000
Echter, terwijl onze pointer wordt geïnitialiseerd,

153
00:07:48,000 --> 00:07:52,000
de gegevens die het wijzend naar zojuist wat junk is dat deel van de heap.

154
00:07:52,000 --> 00:07:55,000
Dus als we die gegevens te laden in int i,

155
00:07:55,000 --> 00:07:57,000
we technisch initialiseren i,

156
00:07:57,000 --> 00:08:00,000
maar we doen dat met junk data.

157
00:08:00,000 --> 00:08:03,000
De oproep om te beweren, dat is een handige debugging macro

158
00:08:03,000 --> 00:08:06,000
gedefinieerd in de toepasselijke naam beweren bibliotheek,

159
00:08:06,000 --> 00:08:09,000
zal afbreken van het programma als de testvoorwaarde mislukt.

160
00:08:09,000 --> 00:08:11,000
Dat wil zeggen, als ik niet 0.

161
00:08:11,000 --> 00:08:14,000
Afhankelijk van wat er in de heap-ruimte, wees door p,

162
00:08:14,000 --> 00:08:18,000
dit programma kan soms werken en niet op andere momenten.

163
00:08:18,000 --> 00:08:20,000
Als het werkt, we net geluk.

164
00:08:20,000 --> 00:08:24,000
De compiler zal niet vangen deze fout, maar Valgrind zeker wil.

165
00:08:24,000 --> 00:08:28,000
Daar zien we de fout als gevolg van ons gebruik van die troep gegevens.

166
00:08:28,000 --> 00:08:32,000
>> Wanneer u heap geheugen toe te wijzen, maar niet vrijgeven het of bevrijden,

167
00:08:32,000 --> 00:08:34,000
dat heet een lek.

168
00:08:34,000 --> 00:08:37,000
Voor een kleine, kortstondige programma dat draait en onmiddellijk verlaat,

169
00:08:37,000 --> 00:08:39,000
lekken zijn vrij onschuldig,

170
00:08:39,000 --> 00:08:42,000
maar voor een project van grotere omvang en / of lange levensduur,

171
00:08:42,000 --> 00:08:46,000
zelfs een klein lek kan verergeren tot iets groot.

172
00:08:46,000 --> 00:08:49,000
Voor CS50, we verwachten dat u

173
00:08:49,000 --> 00:08:51,000
zorgen voor het vrijmaken van alle van de berg geheugen, wat je,

174
00:08:51,000 --> 00:08:54,000
omdat we willen dat u de vaardigheden op te bouwen om goed omgaan met het handmatige proces

175
00:08:54,000 --> 00:08:56,000
vereist C.

176
00:08:56,000 --> 00:08:59,000
Om dit te doen, moet je het programma een exacte

177
00:08:59,000 --> 00:09:03,000
een-op-een correspondentie tussen malloc en gratis bellen.

178
00:09:03,000 --> 00:09:06,000
Gelukkig kunt Valgrind u ook helpen met het geheugen lekken.

179
00:09:06,000 --> 00:09:09,000
Hier is een lekkende programma genaamd leak.c dat toewijst

180
00:09:09,000 --> 00:09:13,000
plaats op de heap, schrijft, maar niet losmaken.

181
00:09:13,000 --> 00:09:16,000
We compileren met Make en voer het onder Valgrind,

182
00:09:16,000 --> 00:09:18,000
en we zien dat, terwijl wij geen geheugen fouten hebben,

183
00:09:18,000 --> 00:09:20,000
we hebben een lek.

184
00:09:20,000 --> 00:09:23,000
Er zijn 16 bytes zeker verloren,

185
00:09:23,000 --> 00:09:27,000
Dit betekent dat de pointer naar dat geheugen niet in omvang als het programma verlaten.

186
00:09:27,000 --> 00:09:30,000
Nu, Valgrind ons niet een ton van informatie over het lek,

187
00:09:30,000 --> 00:09:35,000
maar als we dit kleine er rekening mee dat het geeft naar beneden naar de onderkant van haar verslag

188
00:09:35,000 --> 00:09:38,000
om opnieuw uit te voeren met - lek-check = vol

189
00:09:38,000 --> 00:09:41,000
om de volledige details van gelekt geheugen te zien,

190
00:09:41,000 --> 00:09:44,000
we krijgen meer informatie.

191
00:09:44,000 --> 00:09:46,000
Nu in de heap samenvatting

192
00:09:46,000 --> 00:09:50,000
Valgrind vertelt ons waar het geheugen dat werd verloren werd in eerste instantie toegewezen.

193
00:09:50,000 --> 00:09:52,000
Net zoals we weten uit te kijken in de broncode,

194
00:09:52,000 --> 00:09:55,000
Valgrind informeert ons dat we de herinnering gelekt

195
00:09:55,000 --> 00:09:58,000
toegewezen met een oproep om malloc op lijn 8 van leak.c

196
00:09:58,000 --> 00:10:00,000
in de hoofdfunctie.

197
00:10:00,000 --> 00:10:02,000
Mooie handige.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind categoriseert lekken met behulp van deze termen:

199
00:10:04,000 --> 00:10:07,000
Zeker verloren - dit is heap toegewezen geheugen

200
00:10:07,000 --> 00:10:10,000
waarin het programma niet langer een pointer.

201
00:10:10,000 --> 00:10:14,000
Valgrind weet dat je een keer de aanwijzer had maar sindsdien verloor het.

202
00:10:14,000 --> 00:10:17,000
Dit geheugen is zeker gelekt.

203
00:10:17,000 --> 00:10:20,000
Indirect verloren - dit is heap toegewezen geheugen

204
00:10:20,000 --> 00:10:24,000
welke alleen pointers om ook verloren.

205
00:10:24,000 --> 00:10:27,000
Bijvoorbeeld, als je verloor je pointer naar het eerste knooppunt van een gekoppelde lijst,

206
00:10:27,000 --> 00:10:30,000
dan is het eerste knooppunt zelf zou zeker verloren gaan,

207
00:10:30,000 --> 00:10:34,000
terwijl volgende nodes zou indirect verloren gaan.

208
00:10:34,000 --> 00:10:37,000
Mogelijk verloren - dit is heap toegewezen geheugen

209
00:10:37,000 --> 00:10:41,000
waarin Valgrind niet zeker of er een pointer of niet.

210
00:10:41,000 --> 00:10:44,000
Nog steeds bereikbaar is heap toegewezen geheugen

211
00:10:44,000 --> 00:10:47,000
waaraan nog het programma heeft een pointer bij afslag,

212
00:10:47,000 --> 00:10:50,000
Dit betekent gewoonlijk dat een globale variabele punten aan.

213
00:10:50,000 --> 00:10:53,000
Om te controleren of deze lekken, dan heb je ook de mogelijkheid zijn

214
00:10:53,000 --> 00:10:55,000
- Nog steeds-te bereiken = yes

215
00:10:55,000 --> 00:10:58,000
in uw aanroeping van Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Deze verschillende gevallen kunnen vereisen verschillende strategieën voor het reinigen van hen,

217
00:11:01,000 --> 00:11:05,000
maar lekken moeten worden afgeschaft.

218
00:11:05,000 --> 00:11:08,000
Helaas kan de vaststelling lekken zijn moeilijk om te doen,

219
00:11:08,000 --> 00:11:11,000
omdat onjuiste oproepen naar gratis kunt opblazen uw programma.

220
00:11:11,000 --> 00:11:14,000
Bijvoorbeeld, als we kijken naar invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
zien we een voorbeeld van slecht geheugen vrijmaken.

222
00:11:18,000 --> 00:11:21,000
Wat een aanroep naar de gehele blok vrij

223
00:11:21,000 --> 00:11:24,000
van het geheugen wordt gewezen door int_block,

224
00:11:24,000 --> 00:11:27,000
is maar als een poging om elke int-en kleinbedrijf gedeelte vrij te maken

225
00:11:27,000 --> 00:11:29,000
van het geheugen afzonderlijk.

226
00:11:29,000 --> 00:11:32,000
Dit zal catastrofaal falen.

227
00:11:32,000 --> 00:11:34,000
Boom! Wat een fout.

228
00:11:34,000 --> 00:11:36,000
Dit is zeker niet goed.

229
00:11:36,000 --> 00:11:39,000
Als je vastzit met dit soort fouten, maar, en je weet niet waar je moet kijken,

230
00:11:39,000 --> 00:11:41,000
terug te vallen op uw nieuwe beste vriend.

231
00:11:41,000 --> 00:11:44,000
Je raadt het al - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, zoals altijd, weet precies wat er is.

233
00:11:47,000 --> 00:11:50,000
De Alloc en vrije telt niet met elkaar overeenkomen.

234
00:11:50,000 --> 00:11:52,000
We hebben een Alloc en 4 bevrijdt.

235
00:11:52,000 --> 00:11:55,000
En Valgrind vertelt ons ook waar de eerste slechte free bellen -

236
00:11:55,000 --> 00:11:58,000
degene die de blowup geactiveerd - vandaan komt -

237
00:11:58,000 --> 00:12:00,000
lijn 16.

238
00:12:00,000 --> 00:12:03,000
Zoals u ziet, slechte calls te bevrijden zijn echt slecht,

239
00:12:03,000 --> 00:12:05,000
dus we raden het verhuren van uw programma lek

240
00:12:05,000 --> 00:12:08,000
terwijl je bezig om de functionaliteit correct.

241
00:12:08,000 --> 00:12:12,000
Ga op zoek naar lekken pas na uw programma goed werkt,

242
00:12:12,000 --> 00:12:14,000
zonder enige andere fouten.

243
00:12:14,000 --> 00:12:16,000
>> En dat is alles wat we hebben voor deze video.

244
00:12:16,000 --> 00:12:18,000
Nu, wat wacht je nog op?

245
00:12:18,000 --> 00:12:21,000
Ga op uw programma's Valgrind nu.

246
00:12:21,000 --> 00:12:25,000
Mijn naam is Nate Hardison. Dit is CS50. [CS50.TV]