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
Nogle af de mest vanskelige fejl i C-programmer

5
00:00:10,000 --> 00:00:13,000
kommer fra den dårlige forvaltning af hukommelsen.

6
00:00:13,000 --> 00:00:15,000
Der er et enormt antal måder at skrue tingene op,

7
00:00:15,000 --> 00:00:17,000
herunder fordelingen af ​​den forkerte mængde hukommelse,

8
00:00:17,000 --> 00:00:20,000
glemmer at initialisere variabler,

9
00:00:20,000 --> 00:00:23,000
skrivning før eller efter afslutningen af ​​en puffer,

10
00:00:23,000 --> 00:00:25,000
og frigøre holde hukommelse flere gange.

11
00:00:25,000 --> 00:00:28,000
Symptomerne spænder fra nedbrud

12
00:00:28,000 --> 00:00:30,000
til mystisk overskrevne værdier,

13
00:00:30,000 --> 00:00:34,000
ofte på steder og tidspunkter langt fra den oprindelige fejl.

14
00:00:34,000 --> 00:00:37,000
Sporing den observerede problem tilbage til den underliggende årsag

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

16
00:00:39,000 --> 00:00:42,000
men heldigvis er der en nyttig program kaldet Valgrind

17
00:00:42,000 --> 00:00:44,000
der kan gøre en masse for at hjælpe.

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

19
00:00:47,000 --> 00:00:50,000
omfattende kontrol af dynge hukommelse tildelinger og adgange.

20
00:00:50,000 --> 00:00:53,000
Når Valgrind registrerer et problem, det giver dig øjeblikkelig,

21
00:00:53,000 --> 00:00:56,000
direkte oplysninger, der gør det muligt at

22
00:00:56,000 --> 00:00:58,000
lettere at finde og løse problemet.

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

24
00:01:01,000 --> 00:01:04,000
såsom memory leaks, fordeling dynge hukommelse

25
00:01:04,000 --> 00:01:07,000
og glemmer at frigøre det.

26
00:01:07,000 --> 00:01:10,000
Ligesom vores compiler, Dunk, i vores debugger, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind er fri software, og det er installeret på apparatet.

28
00:01:14,000 --> 00:01:16,000
Valgrind kører på din binære eksekverbare,

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 udarbejdet en up-to-date kopi af dit program

31
00:01:23,000 --> 00:01:25,000
hjælp Dunk Eller Kom.

32
00:01:25,000 --> 00:01:28,000
Derefter kan køre dit program under Valgrind være

33
00:01:28,000 --> 00:01:32,000
så simpelt som bare at forudfastsætte standard program kommandoen med ordet Valgrind,

34
00:01:32,000 --> 00:01:35,000
som starter Valgrind og kører programmet inde i den.

35
00:01:35,000 --> 00:01:38,000
Ved start, Valgrind gør nogle komplekse

36
00:01:38,000 --> 00:01:41,000
jiggering at konfigurere den eksekverbare for hukommelsen checks,

37
00:01:41,000 --> 00:01:44,000
så det kan tage lidt at komme op og køre.

38
00:01:44,000 --> 00:01:48,000
Programmet vil derefter udføre normalt, er det meget langsommere,

39
00:01:48,000 --> 00:01:52,000
og når den er færdig, vil Valgrind udskrive et resumé af sin hukommelse.

40
00:01:52,000 --> 00:01:58,000
Hvis alt går vel, vil det se nogenlunde sådan ud:

41
00:01:58,000 --> 00:02:01,000
I dette tilfælde, /. Clean_program

42
00:02:01,000 --> 00:02:04,000
er stien til det program, jeg vil køre.

43
00:02:04,000 --> 00:02:06,000
Og mens denne ene ikke tager nogen argumenter,

44
00:02:06,000 --> 00:02:09,000
hvis det gjorde jeg ville bare tack dem til slutningen af ​​kommandoen som sædvanlig.

45
00:02:09,000 --> 00:02:12,000
Clean program er bare en dum lille program jeg har oprettet

46
00:02:12,000 --> 00:02:15,000
der tildeler plads til en blok af int'er på heapen,

47
00:02:15,000 --> 00:02:19,000
sætte nogle værdier indeni dem, og frigør hele blokken.

48
00:02:19,000 --> 00:02:23,000
Dette er, hvad du fotograferer for, ingen fejl og ingen utætheder.

49
00:02:23,000 --> 00:02:27,000
>> En anden vigtig parameter er det samlede antal tildelte bytes.

50
00:02:27,000 --> 00:02:32,000
Afhængigt af programmet, hvis dine tildelinger er i megabyte eller højere,

51
00:02:32,000 --> 00:02:34,000
du sikkert gør noget forkert.

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

53
00:02:37,000 --> 00:02:40,000
Bruger du den bunke til opbevaring, når det ville være bedre at bruge stakken?

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

55
00:02:43,000 --> 00:02:46,000
De mere åbenlyse dem forårsager spektakulære krak,

56
00:02:46,000 --> 00:02:49,000
men selv da det kan stadig være svært at lokalisere

57
00:02:49,000 --> 00:02:51,000
hvad der præcist førte til styrtet.

58
00:02:51,000 --> 00:02:54,000
Mere snigende, et program med en hukommelse fejl

59
00:02:54,000 --> 00:02:56,000
kan stadig indsamle rent

60
00:02:56,000 --> 00:02:58,000
og kan stadig synes at arbejde korrekt

61
00:02:58,000 --> 00:03:01,000
fordi du formåede at få heldige det meste af tiden.

62
00:03:01,000 --> 00:03:04,000
Efter flere "positive resultater",

63
00:03:04,000 --> 00:03:07,000
du kan bare tro, at en kollision er et lykketræf af computeren,

64
00:03:07,000 --> 00:03:10,000
men computeren er aldrig forkert.

65
00:03:10,000 --> 00:03:13,000
>> Løb Valgrind kan hjælpe dig med at spore ned årsagen til synlige hukommelsesfejl

66
00:03:13,000 --> 00:03:18,000
samt finde lurer fejl, du behøver ikke engang endnu kender.

67
00:03:18,000 --> 00:03:22,000
Hver gang Valgrind opdager et problem, udskriver information om, hvad det observeret.

68
00:03:22,000 --> 00:03:24,000
Hvert element er temmelig kortfattet -

69
00:03:24,000 --> 00:03:27,000
kildelinjen af ​​de ulovlige instruktion, hvad problemet er,

70
00:03:27,000 --> 00:03:30,000
og lidt info om den pågældende hukommelse -

71
00:03:30,000 --> 00:03:34,000
men ofte er det nok oplysninger til at rette din opmærksomhed mod det rigtige sted.

72
00:03:34,000 --> 00:03:37,000
Her er et eksempel på Valgrind kører på en fejlbehæftet program

73
00:03:37,000 --> 00:03:40,000
der gør en ugyldig læsning af bunke hukommelse.

74
00:03:40,000 --> 00:03:49,000
Vi ser ingen fejl eller advarsler i opgørelsen.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, den fejl resumé siger, at der er to fejl -

76
00:03:53,000 --> 00:03:56,000
to ugyldig læser af størrelse 4 - byte, der er.

77
00:03:56,000 --> 00:04:01,000
Både dårlige læser skete i hovedfunktion invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
den første på linje 16 og den anden på linie 19.

79
00:04:04,000 --> 00:04:06,000
Lad os se på koden.

80
00:04:06,000 --> 00:04:11,000
Ligner den første indkaldelse til printf forsøger at læse en int forbi slutningen af ​​vores hukommelse blok.

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

82
00:04:13,000 --> 00:04:16,000
ser vi, at Valgrind fortalt os præcis det.

83
00:04:16,000 --> 00:04:19,000
Adressen vi prøver at læse starter 0 bytes

84
00:04:19,000 --> 00:04:22,000
forbi enden af ​​blokken af ​​størrelsen 16 byte -

85
00:04:22,000 --> 00:04:25,000
fire 32-bit int'er at vi tildelte.

86
00:04:25,000 --> 00:04:29,000
Det vil sige, den adresse, vi prøvede at læse starter lige i slutningen af ​​vores blok,

87
00:04:29,000 --> 00:04:32,000
ligesom vi ser i vores dårlige printf opkald.

88
00:04:32,000 --> 00:04:36,000
Nu kan ugyldig læser ikke ud som det store af en deal,

89
00:04:36,000 --> 00:04:39,000
men hvis du bruger disse data til at styre strømmen af ​​dit program -

90
00:04:39,000 --> 00:04:42,000
for eksempel som led i en if-sætning eller loop -

91
00:04:42,000 --> 00:04:45,000
så tingene kan lydløst gå dårligt.

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

93
00:04:47,000 --> 00:04:50,000
og intet ud over det sædvanlige sker.

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

95
00:04:52,000 --> 00:04:56,000
>> Nu, lad os se på nogle flere slags fejl, som du kan støde på i din kode,

96
00:04:56,000 --> 00:04:59,000
og vi vil se, hvordan Valgrind registrerer dem.

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

98
00:05:01,000 --> 00:05:04,000
så lad os nu se en invalid_write.

99
00:05:04,000 --> 00:05:09,000
Igen, ingen fejl eller advarsler i opgørelsen.

100
00:05:09,000 --> 00:05:12,000
Okay, Valgrind siger, at der er to fejl i dette program -

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
Lad os se denne kode.

103
00:05:18,000 --> 00:05:21,000
Ser ud til vi har fået et tilfælde af den klassiske strlen plus én fejl.

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

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 gik til at skrive det på ssubstrlen "CS50 rocks!"

107
00:05:30,000 --> 00:05:33,000
det skrev 1 byte forbi slutningen af ​​vores blok.

108
00:05:33,000 --> 00:05:36,000
Den invalid_read kommer, når vi gør vores opfordring til printf.

109
00:05:36,000 --> 00:05:40,000
Printf ender op med at læse ugyldig hukommelse, når den læser / 0 tegn

110
00:05:40,000 --> 00:05:43,000
som det ser ud i slutningen af ​​denne E-strengen, det er udskrivning.

111
00:05:43,000 --> 00:05:45,000
Men intet af dette flygtede Valgrind.

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

113
00:05:48,000 --> 00:05:51,000
på linje 11 i main, den invalid_read og er en del af printf.

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

115
00:05:54,000 --> 00:05:57,000
Igen, kan dette ikke virke som en big deal.

116
00:05:57,000 --> 00:06:00,000
Vi kan køre dette program igen og igen uden for Valgrind

117
00:06:00,000 --> 00:06:03,000
og ikke se nogen fejl symptomer.

118
00:06:03,000 --> 00:06:06,000
>> Men lad os se på en lille variation af dette for at se

119
00:06:06,000 --> 00:06:09,000
hvordan tingene kan blive rigtig slemt.

120
00:06:09,000 --> 00:06:14,000
Så indrømmet, vi misbruger tingene mere end bare en smule i denne kode.

121
00:06:14,000 --> 00:06:17,000
Vi er kun arealfordelingen på heapen til to strenge

122
00:06:17,000 --> 00:06:19,000
længden af ​​CS50 sten,

123
00:06:19,000 --> 00:06:22,000
denne gang, huske / 0 tegn.

124
00:06:22,000 --> 00:06:25,000
Men derefter vi smide i en super-lang streng i hukommelsen blok

125
00:06:25,000 --> 00:06:27,000
at S peger på.

126
00:06:27,000 --> 00:06:30,000
Hvilken effekt vil det have på den lagerblok, at T peger på?

127
00:06:30,000 --> 00:06:34,000
Tja, hvis T-point til hukommelse, der er bare støder op til S,

128
00:06:34,000 --> 00:06:37,000
kommer lige efter det,

129
00:06:37,000 --> 00:06:39,000
så vi kunne have skrevet over en del af T.

130
00:06:39,000 --> 00:06:41,000
Lad os køre denne kode.

131
00:06:41,000 --> 00:06:43,000
Se på, hvad der skete.

132
00:06:43,000 --> 00:06:47,000
Strengene vi gemt i vores bunke blokke begge syntes at have udskrevet korrekt.

133
00:06:47,000 --> 00:06:49,000
Intet virker forkert overhovedet.

134
00:06:49,000 --> 00:06:52,000
Men lad os gå tilbage til vores kode og

135
00:06:52,000 --> 00:06:55,000
udkommentere den linje, hvor vi kopierer CS50 klipper

136
00:06:55,000 --> 00:06:59,000
ind i den anden hukommelse blok, der peges på af t.

137
00:06:59,000 --> 00:07:02,000
Nu, når vi kører denne kode bør vi

138
00:07:02,000 --> 00:07:06,000
kun indholdet af den første lagerblok printe ud.

139
00:07:06,000 --> 00:07:09,000
Whoa, selvom vi ikke str kopi

140
00:07:09,000 --> 00:07:12,000
alle tegn i den anden bunke blok, den ene peget på af T,

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

142
00:07:15,000 --> 00:07:18,000
Faktisk strengen vi proppet ind i vores første blok

143
00:07:18,000 --> 00:07:21,000
overskred den første blok og ind i den anden blok,

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

145
00:07:23,000 --> 00:07:26,000
Valgrind dog fortæller os den sande historie.

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

147
00:07:28,000 --> 00:07:32,000
Alle dem ugyldige læser og skriver.

148
00:07:32,000 --> 00:07:36,000
>> Lad os se på et eksempel på en anden form for fejl.

149
00:07:36,000 --> 00:07:39,000
Her gør vi noget ret uheldigt.

150
00:07:39,000 --> 00:07:41,000
Vi grab plads til en int på heapen,

151
00:07:41,000 --> 00:07:45,000
og vi initialisere en int pointer - p - at pege på den plads.

152
00:07:45,000 --> 00:07:48,000
Men mens vores pointer er initialiseret,

153
00:07:48,000 --> 00:07:52,000
de data, den peger mod netop har uanset junk er i den del af dyngen.

154
00:07:52,000 --> 00:07:55,000
Så når vi indlæse disse data i 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 gør det med junk data.

157
00:08:00,000 --> 00:08:03,000
Opfordringen til at hævde, som er en praktisk debugging makro

158
00:08:03,000 --> 00:08:06,000
defineret i det passende navn hævde bibliotek,

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

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

161
00:08:11,000 --> 00:08:14,000
Afhængigt af hvad der var i den bunke rummet, at ved p pegede,

162
00:08:14,000 --> 00:08:18,000
dette program kan arbejde nogle gange og mislykkes på andre tidspunkter.

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

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

165
00:08:24,000 --> 00:08:28,000
Der ser vi den fejl som følge af vores brug af denne junk data.

166
00:08:28,000 --> 00:08:32,000
>> Når du allokerer dynge hukommelse, men ikke deallocate det eller frigøre det,

167
00:08:32,000 --> 00:08:34,000
, som kaldes en lækage.

168
00:08:34,000 --> 00:08:37,000
For en lille, kortvarig program, der kører og straks udgange,

169
00:08:37,000 --> 00:08:39,000
lækager er ret harmløs,

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

171
00:08:42,000 --> 00:08:46,000
selv en lille utæthed kan forværre til noget 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
tage sig af at befri alle de bunke hukommelse, som du tildeler,

174
00:08:51,000 --> 00:08:54,000
da vi ønsker, at du opbygge de færdigheder til korrekt håndtere den manuelle proces

175
00:08:54,000 --> 00:08:56,000
kræves C.

176
00:08:56,000 --> 00:08:59,000
For at gøre det, skal dit program har en eksakt

177
00:08:59,000 --> 00:09:03,000
en-til-en overensstemmelse mellem allokere og gratis opkald.

178
00:09:03,000 --> 00:09:06,000
Heldigvis kan Valgrind hjælpe dig med memory leaks også.

179
00:09:06,000 --> 00:09:09,000
Her er en utæt program kaldet leak.c at tildeler

180
00:09:09,000 --> 00:09:13,000
plads på heapen, skriver til det, men ikke frigøre det.

181
00:09:13,000 --> 00:09:16,000
Vi sammensætter det med Make og køre det under Valgrind,

182
00:09:16,000 --> 00:09:18,000
og vi kan se, at selv om vi ikke har nogen hukommelse fejl,

183
00:09:18,000 --> 00:09:20,000
vi har en lækage.

184
00:09:20,000 --> 00:09:23,000
Der er 16 bytes absolut tabt,

185
00:09:23,000 --> 00:09:27,000
hvilket betyder, at markøren til at hukommelsen ikke var i rækkevidde når programmet forlades.

186
00:09:27,000 --> 00:09:30,000
Nu ser Valgrind ikke give os et ton af oplysninger om lækagen,

187
00:09:30,000 --> 00:09:35,000
men hvis vi følger denne lille note, at det giver ned mod bunden af ​​sin rapport

188
00:09:35,000 --> 00:09:38,000
at køre med - lækage-check = fuld

189
00:09:38,000 --> 00:09:41,000
at se de fulde detaljer om lækket hukommelse,

190
00:09:41,000 --> 00:09:44,000
vi får mere information.

191
00:09:44,000 --> 00:09:46,000
Nu, i bunke resumé,

192
00:09:46,000 --> 00:09:50,000
Valgrind fortæller os, hvor den hukommelse, der blev tabt oprindeligt var tildelt.

193
00:09:50,000 --> 00:09:52,000
Ligesom vi kender det fra at kigge i kildekoden,

194
00:09:52,000 --> 00:09:55,000
Valgrind informerer os, at vi lækkede hukommelsen

195
00:09:55,000 --> 00:09:58,000
fordelt med en opfordring til malloc på linje 8 i leak.c

196
00:09:58,000 --> 00:10:00,000
i hovedfunktion.

197
00:10:00,000 --> 00:10:02,000
Temmelig smart.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind kategoriserer utætheder ved hjælp af disse ord:

199
00:10:04,000 --> 00:10:07,000
Absolut tabt - det er heap allokeret hukommelse

200
00:10:07,000 --> 00:10:10,000
som programmet ikke længere har en pointer.

201
00:10:10,000 --> 00:10:14,000
Valgrind ved, at du engang havde markøren, men har siden mistet styr på det.

202
00:10:14,000 --> 00:10:17,000
Denne hukommelse er absolut lækket.

203
00:10:17,000 --> 00:10:20,000
Indirekte tabt - det er heap allokeret hukommelse

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

205
00:10:24,000 --> 00:10:27,000
For eksempel, hvis du har mistet din pointer til den første node af en linket liste

206
00:10:27,000 --> 00:10:30,000
derefter det første knudepunkt selv ville blive endeligt tabt,

207
00:10:30,000 --> 00:10:34,000
mens eventuelle efterfølgende knuder ville indirekte tabt.

208
00:10:34,000 --> 00:10:37,000
Muligvis tabt - det er heap allokeret hukommelse

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

210
00:10:41,000 --> 00:10:44,000
Stadig nås er heap allokeret hukommelse

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

212
00:10:47,000 --> 00:10:50,000
hvilket typisk betyder, at en global variabel peger på det.

213
00:10:50,000 --> 00:10:53,000
At kontrollere for disse lækager, vil du også nødt til at omfatte mulighed

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

215
00:10:55,000 --> 00:10:58,000
i din påkaldelse af Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Disse forskellige tilfælde kan kræve forskellige strategier for at rense dem op,

217
00:11:01,000 --> 00:11:05,000
men lækager bør fjernes.

218
00:11:05,000 --> 00:11:08,000
Desværre kan fastsætte lækager være svært at gøre,

219
00:11:08,000 --> 00:11:11,000
idet forkerte opkald til gratis kan sprænge dit program.

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 deallokering.

222
00:11:18,000 --> 00:11:21,000
Hvad bør være et enkelt opkald for at befri hele blokken

223
00:11:21,000 --> 00:11:24,000
hukommelse peges på af int_block,

224
00:11:24,000 --> 00:11:27,000
er i stedet blevet et forsøg på at befri hver int-sized sektion

225
00:11:27,000 --> 00:11:29,000
af hukommelsen individuelt.

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

227
00:11:32,000 --> 00:11:34,000
Boom! Hvad en fejl.

228
00:11:34,000 --> 00:11:36,000
Dette er absolut ikke godt.

229
00:11:36,000 --> 00:11:39,000
Hvis du sidder fast med denne form for fejl, selv om, og du behøver ikke vide hvor man skal lede,

230
00:11:39,000 --> 00:11:41,000
falde tilbage på din nye bedste ven.

231
00:11:41,000 --> 00:11:44,000
Du gættede det - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, som altid ved præcis, hvad der sker.

233
00:11:47,000 --> 00:11:50,000
Alloc og gratis tæller ikke passer sammen.

234
00:11:50,000 --> 00:11:52,000
Vi har fået 1 alloc og 4 Frees.

235
00:11:52,000 --> 00:11:55,000
Og Valgrind også fortæller os, hvor den første dårlige gratis opkald -

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

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

238
00:12:00,000 --> 00:12:03,000
Som du kan se, dårlige opkald til fri er virkelig dårlig,

239
00:12:03,000 --> 00:12:05,000
så vi anbefaler at lade dit program lækage

240
00:12:05,000 --> 00:12:08,000
mens du arbejder på at få funktionaliteten korrekt.

241
00:12:08,000 --> 00:12:12,000
Begynder at lede efter lækager, når dit program fungerer korrekt,

242
00:12:12,000 --> 00:12:14,000
uden andre fejl.

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

244
00:12:16,000 --> 00:12:18,000
Nu, hvad venter du på?

245
00:12:18,000 --> 00:12:21,000
Go køre Valgrind på dine programmer lige nu.

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