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
Dette er CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
Noen av de vanskeligste feil i C-programmer

5
00:00:10,000 --> 00:00:13,000
kommer fra vanstyre av minnet.

6
00:00:13,000 --> 00:00:15,000
Det er et stort antall måter å skru opp ting,

7
00:00:15,000 --> 00:00:17,000
inkludert tildeling feil mengde minne,

8
00:00:17,000 --> 00:00:20,000
glemme å initialisere variabler,

9
00:00:20,000 --> 00:00:23,000
skriftlig før eller etter slutten av en buffer,

10
00:00:23,000 --> 00:00:25,000
og frigjøre holde minne flere ganger.

11
00:00:25,000 --> 00:00:28,000
Symptomene varierer fra intermitterende krasj

12
00:00:28,000 --> 00:00:30,000
til mystisk overskrevet verdier,

13
00:00:30,000 --> 00:00:34,000
ofte på steder og tider fjernt fra den opprinnelige feilen.

14
00:00:34,000 --> 00:00:37,000
Tracing den observerte problemet tilbake til den underliggende årsaken

15
00:00:37,000 --> 00:00:39,000
kan være utfordrende,

16
00:00:39,000 --> 00:00:42,000
men heldigvis er det en nyttig program som heter Valgrind

17
00:00:42,000 --> 00:00:44,000
som kan gjøre mye for å hjelpe.

18
00:00:44,000 --> 00:00:47,000
>> Du kjører et program under Valgrind å aktivere

19
00:00:47,000 --> 00:00:50,000
omfattende kontroll av heap minnetildelinger og tilganger.

20
00:00:50,000 --> 00:00:53,000
Når Valgrind oppdager et problem, det gir deg umiddelbar,

21
00:00:53,000 --> 00:00:56,000
direkte informasjon som gjør det mulig å

22
00:00:56,000 --> 00:00:58,000
enklere å finne og løse problemet.

23
00:00:58,000 --> 00:01:01,000
Valgrind også rapporter om mindre dødelige minneproblemer,

24
00:01:01,000 --> 00:01:04,000
som minnelekkasjer, fordele heap minne,

25
00:01:04,000 --> 00:01:07,000
og glemmer å frigjøre den.

26
00:01:07,000 --> 00:01:10,000
Liker vår kompilator, Clang i debugger vår, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind er fri programvare, og det er installert på maskinen.

28
00:01:14,000 --> 00:01:16,000
Valgrind kjører på binær kjørbar,

29
00:01:16,000 --> 00:01:20,000
ikke din. c eller. h kildekodefiler,

30
00:01:20,000 --> 00:01:23,000
så vær sikker på at du har satt sammen en up-to-date kopi av programmet

31
00:01:23,000 --> 00:01:25,000
bruker Clang eller Make.

32
00:01:25,000 --> 00:01:28,000
Deretter kan kjøre program under Valgrind være

33
00:01:28,000 --> 00:01:32,000
så enkelt som bare prefixing standard programkommando med ordet Valgrind,

34
00:01:32,000 --> 00:01:35,000
som starter opp Valgrind og kjører programmet på innsiden av det.

35
00:01:35,000 --> 00:01:38,000
Når du starter, gjør Valgrind noen komplekse

36
00:01:38,000 --> 00:01:41,000
jiggering å konfigurere den kjørbare for minne sjekker,

37
00:01:41,000 --> 00:01:44,000
så det kan ta litt for å få opp og kjører.

38
00:01:44,000 --> 00:01:48,000
Programmet vil da kjøre normalt, det være seg mye saktere,

39
00:01:48,000 --> 00:01:52,000
og når den er ferdig, vil Valgrind skrive ut et sammendrag av sin minnebruk.

40
00:01:52,000 --> 00:01:58,000
Hvis alt går bra, vil det se omtrent slik ut:

41
00:01:58,000 --> 00:02:01,000
I dette tilfellet,. / Clean_program

42
00:02:01,000 --> 00:02:04,000
er banen til det programmet jeg ønsker å kjøre.

43
00:02:04,000 --> 00:02:06,000
Og mens dette ikke tar noen argumenter,

44
00:02:06,000 --> 00:02:09,000
hvis det gjorde jeg ville bare tack dem videre til slutten av kommandoen som vanlig.

45
00:02:09,000 --> 00:02:12,000
Ren programmet er bare en dum liten program jeg har laget

46
00:02:12,000 --> 00:02:15,000
som tildeler plass for en blokk med ints på haugen,

47
00:02:15,000 --> 00:02:19,000
sette noen tall inne i dem, og frigjør hele blokken.

48
00:02:19,000 --> 00:02:23,000
Dette er hva du fotograferer for, ingen feil og ingen lekkasjer.

49
00:02:23,000 --> 00:02:27,000
>> En annen viktig faktor er det totale antall byte tildelt.

50
00:02:27,000 --> 00:02:32,000
Avhengig av programmet, hvis bevilgningene er i megabyte eller høyere,

51
00:02:32,000 --> 00:02:34,000
du sannsynligvis har gjort noe galt.

52
00:02:34,000 --> 00:02:37,000
Er du unødvendig lagring duplikater?

53
00:02:37,000 --> 00:02:40,000
Bruker du haugen for lagring, da det ville være bedre å bruke stabelen?

54
00:02:40,000 --> 00:02:43,000
Så kan minnefeil være virkelig onde.

55
00:02:43,000 --> 00:02:46,000
De mer synlige som forårsaker spektakulære krasj,

56
00:02:46,000 --> 00:02:49,000
men selv da kan det likevel være vanskelig å finne

57
00:02:49,000 --> 00:02:51,000
hva førte til ulykken.

58
00:02:51,000 --> 00:02:54,000
Mer snikende, et program med en minne feil

59
00:02:54,000 --> 00:02:56,000
kan fortsatt kompilere ren

60
00:02:56,000 --> 00:02:58,000
og kan fortsatt synes å fungere riktig

61
00:02:58,000 --> 00:03:01,000
fordi du klarte å få heldige mesteparten av tiden.

62
00:03:01,000 --> 00:03:04,000
Etter flere "vellykkede resultater,"

63
00:03:04,000 --> 00:03:07,000
du kan bare tenke at en krasj er en fluke av datamaskinen,

64
00:03:07,000 --> 00:03:10,000
men datamaskinen er aldri feil.

65
00:03:10,000 --> 00:03:13,000
>> Kjører Valgrind kan hjelpe deg med å spore årsaken til synlige minne feil

66
00:03:13,000 --> 00:03:18,000
samt finne lurking feil du ikke selv ennå vet om.

67
00:03:18,000 --> 00:03:22,000
Hver gang Valgrind oppdager et problem, skriver den informasjon om hva det observert.

68
00:03:22,000 --> 00:03:24,000
Hvert element er ganske konsis -

69
00:03:24,000 --> 00:03:27,000
kilden linjen av den fornærmende instruksjon, hva problemet er,

70
00:03:27,000 --> 00:03:30,000
og litt info om minnet involvert -

71
00:03:30,000 --> 00:03:34,000
men ofte er det nok informasjon til å rette oppmerksomheten din til rett sted.

72
00:03:34,000 --> 00:03:37,000
Her er et eksempel på Valgrind kjører på en buggy program

73
00:03:37,000 --> 00:03:40,000
som gjør en ugyldig lese av heap minne.

74
00:03:40,000 --> 00:03:49,000
Vi ser ingen feil eller advarsler i samlingen.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, sier Feillisten at det er to feil -

76
00:03:53,000 --> 00:03:56,000
to ugyldig lesninger av størrelse 4 - bytes, som er.

77
00:03:56,000 --> 00:04:01,000
Både dårlig leser skjedde i den viktigste funksjonen til invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
først på linje 16 og den andre på linje 19.

79
00:04:04,000 --> 00:04:06,000
La oss se på koden.

80
00:04:06,000 --> 00:04:11,000
Ser ut som den første samtalen til printf forsøker å lese en int forbi slutten av vår hukommelse blokk.

81
00:04:11,000 --> 00:04:13,000
Hvis vi ser tilbake på Valgrind utgang,

82
00:04:13,000 --> 00:04:16,000
Vi ser at Valgrind fortalte oss akkurat det.

83
00:04:16,000 --> 00:04:19,000
Adressen vi prøver å lese starter 0 byte

84
00:04:19,000 --> 00:04:22,000
forbi enden av blokken av størrelse 16 byte -

85
00:04:22,000 --> 00:04:25,000
fire 32-bits ints som vi tildelt.

86
00:04:25,000 --> 00:04:29,000
Det vil si, begynner adressen vi prøvde å lese helt på slutten av blokken vår,

87
00:04:29,000 --> 00:04:32,000
akkurat som vi ser i vår dårlig printf samtale.

88
00:04:32,000 --> 00:04:36,000
Nå kan ugyldig reads ikke virke som den store av en avtale,

89
00:04:36,000 --> 00:04:39,000
men hvis du bruker disse dataene til å kontrollere flyten av programmet -

90
00:04:39,000 --> 00:04:42,000
for eksempel som en del av en hvis setningen eller sløyfe -

91
00:04:42,000 --> 00:04:45,000
så ting kan stille gå dårlig.

92
00:04:45,000 --> 00:04:47,000
Se hvordan jeg kan kjøre invalid_read program

93
00:04:47,000 --> 00:04:50,000
og ingenting utenom det vanlige skjer.

94
00:04:50,000 --> 00:04:52,000
Skremmende, ikke sant?

95
00:04:52,000 --> 00:04:56,000
>> Nå, la oss se på noen flere typer feil som kan oppstå i koden,

96
00:04:56,000 --> 00:04:59,000
og vi får se hvordan Valgrind oppdager dem.

97
00:04:59,000 --> 00:05:01,000
Vi så et eksempel på en invalid_read,

98
00:05:01,000 --> 00:05:04,000
så nå la oss sjekke ut en invalid_write.

99
00:05:04,000 --> 00:05:09,000
Igjen, ingen feil eller advarsler i samlingen.

100
00:05:09,000 --> 00:05:12,000
Ok, sier Valgrind at det er to feil i dette programmet -

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

102
00:05:15,000 --> 00:05:18,000
La oss sjekke ut denne koden.

103
00:05:18,000 --> 00:05:21,000
Ser ut som vi har fått en forekomst av den klassiske strlen pluss en bug.

104
00:05:21,000 --> 00:05:24,000
Koden ikke malloc en ekstra byte plass

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

106
00:05:26,000 --> 00:05:30,000
så når str kopi gikk for å skrive det på ssubstrlen "CS50 rocks!"

107
00:05:30,000 --> 00:05:33,000
det skrev en byte forbi slutten av blokken vår.

108
00:05:33,000 --> 00:05:36,000
Den invalid_read kommer når vi gjør vår oppfordring til printf.

109
00:05:36,000 --> 00:05:40,000
Printf ender opp med å lese ugyldig minne når den leser / 0 karakter

110
00:05:40,000 --> 00:05:43,000
som det ser ut på slutten av denne E strengen er det utskrift.

111
00:05:43,000 --> 00:05:45,000
Men ingenting av dette rømte Valgrind.

112
00:05:45,000 --> 00:05:48,000
Vi ser at det fanget invalid_write som en del av str kopi

113
00:05:48,000 --> 00:05:51,000
on line 11 av main og invalid_read er en del av printf.

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

115
00:05:54,000 --> 00:05:57,000
Igjen, dette kan ikke virke som en stor avtale.

116
00:05:57,000 --> 00:06:00,000
Vi kan kjøre dette programmet og om igjen utenfor Valgrind

117
00:06:00,000 --> 00:06:03,000
og ikke se noen feil symptomer.

118
00:06:03,000 --> 00:06:06,000
>> Men la oss se på en liten variant av dette for å se

119
00:06:06,000 --> 00:06:09,000
hvordan ting kan bli virkelig ille.

120
00:06:09,000 --> 00:06:14,000
Så, gitt, er vi misbruker ting mer enn bare litt i denne koden.

121
00:06:14,000 --> 00:06:17,000
Vi bare tildeles plass på haugen for to strenger

122
00:06:17,000 --> 00:06:19,000
lengden på CS50 bergarter,

123
00:06:19,000 --> 00:06:22,000
denne gangen, husker / 0 karakter.

124
00:06:22,000 --> 00:06:25,000
Men da vi kaste i en super-lang streng inn i minnet blokk

125
00:06:25,000 --> 00:06:27,000
at S peker til.

126
00:06:27,000 --> 00:06:30,000
Hvilken effekt vil det ha på minnet blokken T peker på?

127
00:06:30,000 --> 00:06:34,000
Vel, hvis T peker på minne det er bare ved siden av S,

128
00:06:34,000 --> 00:06:37,000
kommer rett etter det,

129
00:06:37,000 --> 00:06:39,000
så vi kan ha skrevet over en del av T.

130
00:06:39,000 --> 00:06:41,000
La oss kjøre denne koden.

131
00:06:41,000 --> 00:06:43,000
Se på hva som skjedde.

132
00:06:43,000 --> 00:06:47,000
Strengene vi lagret i våre heap blokker både syntes å ha skrevet ut riktig.

133
00:06:47,000 --> 00:06:49,000
Ingenting virker galt i det hele tatt.

134
00:06:49,000 --> 00:06:52,000
Men la oss gå tilbake til koden vår og

135
00:06:52,000 --> 00:06:55,000
kommentere ut linjen der vi kopierer CS50 bergarter

136
00:06:55,000 --> 00:06:59,000
inn i andre minneblokk, pekte på av t.

137
00:06:59,000 --> 00:07:02,000
Nå, når vi kjører denne koden vi bør

138
00:07:02,000 --> 00:07:06,000
bare se innholdet i den første minneblokk skrive ut.

139
00:07:06,000 --> 00:07:09,000
Jøss, selv om vi ikke str kopi

140
00:07:09,000 --> 00:07:12,000
noen tegn til den andre haugen blokken, pekte en til av T,

141
00:07:12,000 --> 00:07:15,000
vi får en utskrift.

142
00:07:15,000 --> 00:07:18,000
Faktisk strengen vi fylt inn i vår første kvartal

143
00:07:18,000 --> 00:07:21,000
overkjørte den første blokken og inn i den andre blokka,

144
00:07:21,000 --> 00:07:23,000
gjør alt synes normalt.

145
00:07:23,000 --> 00:07:26,000
Valgrind, men forteller oss den sanne historien.

146
00:07:26,000 --> 00:07:28,000
Det vi går.

147
00:07:28,000 --> 00:07:32,000
Alle disse ugyldig leser og skriver.

148
00:07:32,000 --> 00:07:36,000
>> La oss se på et eksempel på en annen type feil.

149
00:07:36,000 --> 00:07:39,000
Her har vi å gjøre noe ganske uheldig.

150
00:07:39,000 --> 00:07:41,000
Vi grip plass til en int på haugen,

151
00:07:41,000 --> 00:07:45,000
og vi initialisere en int spisser - p - å peke på det rommet.

152
00:07:45,000 --> 00:07:48,000
Men mens våre pekeren er initialisert,

153
00:07:48,000 --> 00:07:52,000
dataene at det peker til bare har uansett junk ligger i den delen av haugen.

154
00:07:52,000 --> 00:07:55,000
Så når vi laster dataene inn int i,

155
00:07:55,000 --> 00:07:57,000
vi teknisk initialisere i,

156
00:07:57,000 --> 00:08:00,000
Men vi gjør det med søppel data.

157
00:08:00,000 --> 00:08:03,000
Kallet til å hevde, som er en hendig debugging makro

158
00:08:03,000 --> 00:08:06,000
definert i det treffende navnet hevde bibliotek,

159
00:08:06,000 --> 00:08:09,000
vil avbryte programmet hvis det testbetingelse mislykkes.

160
00:08:09,000 --> 00:08:11,000
Det vil si, hvis jeg ikke er 0.

161
00:08:11,000 --> 00:08:14,000
Avhengig av hva var i haugen plass, peker til p,

162
00:08:14,000 --> 00:08:18,000
dette programmet kan fungere noen ganger og mislykkes på andre tidspunkter.

163
00:08:18,000 --> 00:08:20,000
Hvis det fungerer, vi bare få heldige.

164
00:08:20,000 --> 00:08:24,000
Kompilatoren vil ikke fange denne feilen, men Valgrind sikker vilje.

165
00:08:24,000 --> 00:08:28,000
Der ser vi feilen stammer fra vår bruk av som useriøs data.

166
00:08:28,000 --> 00:08:32,000
>> Når du tildeler heap minne, men ikke deallocate det eller frigjøre det,

167
00:08:32,000 --> 00:08:34,000
som kalles en lekkasje.

168
00:08:34,000 --> 00:08:37,000
For en liten, kortvarig program som kjører og umiddelbart kommer ut,

169
00:08:37,000 --> 00:08:39,000
lekkasjer er ganske ufarlig,

170
00:08:39,000 --> 00:08:42,000
men for et prosjekt av større størrelse og / eller levetid,

171
00:08:42,000 --> 00:08:46,000
selv en liten lekkasje kan forverre seg til noe større.

172
00:08:46,000 --> 00:08:49,000
For CS50, forventer vi at du

173
00:08:49,000 --> 00:08:51,000
ta vare på frigjøre alle av haugen minne som du fordele,

174
00:08:51,000 --> 00:08:54,000
siden vi ønsker å bygge kompetanse til å riktig håndtere den manuelle prosessen

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

176
00:08:56,000 --> 00:08:59,000
Å gjøre det, bør programmet ha en eksakt

177
00:08:59,000 --> 00:09:03,000
en-til-en-forhold mellom malloc og gratis samtaler.

178
00:09:03,000 --> 00:09:06,000
Heldigvis kan Valgrind hjelpe deg med minnelekkasjer også.

179
00:09:06,000 --> 00:09:09,000
Her er en lekk program som heter leak.c som tildeler

180
00:09:09,000 --> 00:09:13,000
plass på haugen, skriver til den, men frigjøre ikke det.

181
00:09:13,000 --> 00:09:16,000
Vi kompilere den med Lag og kjøre den under Valgrind,

182
00:09:16,000 --> 00:09:18,000
og vi ser at mens vi har ingen minnefeil,

183
00:09:18,000 --> 00:09:20,000
Vi har en lekkasje.

184
00:09:20,000 --> 00:09:23,000
Det er 16 byte definitivt tapt,

185
00:09:23,000 --> 00:09:27,000
noe som betyr at pekeren til at minnet var ikke i omfang når programmet avsluttes.

186
00:09:27,000 --> 00:09:30,000
Nå, Valgrind ikke gi oss massevis av informasjon om lekkasjen,

187
00:09:30,000 --> 00:09:35,000
men hvis vi følger denne lille oppmerksom på at det gir ned mot bunnen av rapporten

188
00:09:35,000 --> 00:09:38,000
å kjøre med - lekkasje-sjekk = full

189
00:09:38,000 --> 00:09:41,000
å se detaljer lekket minne,

190
00:09:41,000 --> 00:09:44,000
vi får mer informasjon.

191
00:09:44,000 --> 00:09:46,000
Nå, i haugen sammendraget,

192
00:09:46,000 --> 00:09:50,000
Valgrind forteller oss hvor minnet som gikk tapt var opprinnelig tildelt.

193
00:09:50,000 --> 00:09:52,000
Akkurat som vi vet fra å se i kildekoden,

194
00:09:52,000 --> 00:09:55,000
Valgrind forteller oss at vi lekket minnet

195
00:09:55,000 --> 00:09:58,000
fordeles med en oppfordring til malloc på linje 8 av leak.c

196
00:09:58,000 --> 00:10:00,000
i den viktigste funksjonen.

197
00:10:00,000 --> 00:10:02,000
Ganske kjekk liten.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind kategoriserer lekkasjer ved hjelp av disse begrepene:

199
00:10:04,000 --> 00:10:07,000
Definitivt mistet - dette er heap allokert minne

200
00:10:07,000 --> 00:10:10,000
som programmet ikke lenger har en peker.

201
00:10:10,000 --> 00:10:14,000
Valgrind vet at du en gang hadde pekeren, men har siden mistet oversikten over det.

202
00:10:14,000 --> 00:10:17,000
Dette minnet er definitivt lekket.

203
00:10:17,000 --> 00:10:20,000
Indirekte tapt - dette er heap allokert minne

204
00:10:20,000 --> 00:10:24,000
som de eneste pekere til det også går tapt.

205
00:10:24,000 --> 00:10:27,000
For eksempel, hvis du har mistet pekeren til den første noden en lenket liste,

206
00:10:27,000 --> 00:10:30,000
da den første noden selv ville være definitivt tapt,

207
00:10:30,000 --> 00:10:34,000
mens eventuelle etterfølgende noder vil bli indirekte tapt.

208
00:10:34,000 --> 00:10:37,000
Muligens tapt - dette er heap allokert minne

209
00:10:37,000 --> 00:10:41,000
som Valgrind ikke kan være sikker på om det er en peker eller ikke.

210
00:10:41,000 --> 00:10:44,000
Fortsatt kan nås er heap allokert minne

211
00:10:44,000 --> 00:10:47,000
som programmet fortsatt har en peker på exit,

212
00:10:47,000 --> 00:10:50,000
som betyr vanligvis at en global variabel poeng til det.

213
00:10:50,000 --> 00:10:53,000
For å se etter disse lekkasjene, vil du også nødt til å inkludere muligheten

214
00:10:53,000 --> 00:10:55,000
- Fortsatt-nås = yes

215
00:10:55,000 --> 00:10:58,000
i påkallelse av Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Disse ulike tilfeller kan kreve ulike strategier for å rense dem opp,

217
00:11:01,000 --> 00:11:05,000
men lekkasjer bør elimineres.

218
00:11:05,000 --> 00:11:08,000
Dessverre kan fikse lekkasjer være vanskelig å gjøre,

219
00:11:08,000 --> 00:11:11,000
siden feil samtaler til gratis kan blåse opp programmet.

220
00:11:11,000 --> 00:11:14,000
For eksempel, hvis vi ser på invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
ser vi et eksempel på dårlig hukommelse deallocation.

222
00:11:18,000 --> 00:11:21,000
Hva bør være en enkel samtale for å frigjøre hele blokken

223
00:11:21,000 --> 00:11:24,000
minne peker til int_block,

224
00:11:24,000 --> 00:11:27,000
har i stedet blitt et forsøk på å frigjøre hver int størrelse seksjon

225
00:11:27,000 --> 00:11:29,000
av minnet individuelt.

226
00:11:29,000 --> 00:11:32,000
Dette vil mislykkes katastrofalt.

227
00:11:32,000 --> 00:11:34,000
Boom! Hva en feil.

228
00:11:34,000 --> 00:11:36,000
Dette er definitivt ikke bra.

229
00:11:36,000 --> 00:11:39,000
Hvis du sitter fast med denne typen feil, skjønt, og du vet ikke hvor du skal lete,

230
00:11:39,000 --> 00:11:41,000
falle tilbake på din nye bestevenn.

231
00:11:41,000 --> 00:11:44,000
Du gjettet det - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, som alltid, vet nøyaktig hva som skjer.

233
00:11:47,000 --> 00:11:50,000
Alloc og gratis teller ikke samsvarer.

234
00:11:50,000 --> 00:11:52,000
Vi har en Alloc og 4 frigjør.

235
00:11:52,000 --> 00:11:55,000
Og Valgrind forteller oss også hvor den første dårlig gratis samtale -

236
00:11:55,000 --> 00:11:58,000
den som utløste blowup - kommer fra -

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

238
00:12:00,000 --> 00:12:03,000
Som du ser, dårlige samtaler til gratis er virkelig ille,

239
00:12:03,000 --> 00:12:05,000
så vi anbefaler å la programmet lekkasje

240
00:12:05,000 --> 00:12:08,000
mens du jobber med å få funksjonaliteten riktig.

241
00:12:08,000 --> 00:12:12,000
Begynne å lete etter lekkasjer etter at programmet fungerer som det skal,

242
00:12:12,000 --> 00:12:14,000
uten andre feil.

243
00:12:14,000 --> 00:12:16,000
>> Og det er alt vi har for denne videoen.

244
00:12:16,000 --> 00:12:18,000
Nå hva venter du på?

245
00:12:18,000 --> 00:12:21,000
Gå kjøre Valgrind i dine programmer akkurat nå.

246
00:12:21,000 --> 00:12:25,000
Mitt navn er Nate Hardison. Dette er CS50. [CS50.TV]