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 Universiteit]

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

4
00:00:07,000 --> 00:00:10,000
Sommige van die moeilikste foute in C-programme

5
00:00:10,000 --> 00:00:13,000
kom van die wanbestuur van die geheue.

6
00:00:13,000 --> 00:00:15,000
Daar is 'n groot aantal van maniere om dinge te skroef,

7
00:00:15,000 --> 00:00:17,000
insluitend die toekenning van die verkeerde bedrag van die geheue,

8
00:00:17,000 --> 00:00:20,000
vergeet veranderlikes te inisialiseer,

9
00:00:20,000 --> 00:00:23,000
skriftelik voor of na die einde van 'n buffer,

10
00:00:23,000 --> 00:00:25,000
en bevry hou geheue verskeie kere.

11
00:00:25,000 --> 00:00:28,000
Die simptome wissel van 'n onderbroke crashes

12
00:00:28,000 --> 00:00:30,000
geheimsinnig oorskryf waardes,

13
00:00:30,000 --> 00:00:34,000
dikwels op plekke en tye wat ver verwyderd van die oorspronklike fout.

14
00:00:34,000 --> 00:00:37,000
Die opsporing van die waargenome probleem terug na die onderliggende oorsaak

15
00:00:37,000 --> 00:00:39,000
kan wees uitdagend,

16
00:00:39,000 --> 00:00:42,000
maar gelukkig is daar is 'n nuttige program genaamd Valgrind

17
00:00:42,000 --> 00:00:44,000
wat kan 'n baie doen om te help.

18
00:00:44,000 --> 00:00:47,000
>> Jy 'n program onder Valgrind in staat te stel

19
00:00:47,000 --> 00:00:50,000
uitgebreide kontrolering van hoop geheue toekennings en toegange.

20
00:00:50,000 --> 00:00:53,000
Wanneer Valgrind ontdek 'n probleem, dit gee jou onmiddellike,

21
00:00:53,000 --> 00:00:56,000
direkte inligting wat u toelaat om

22
00:00:56,000 --> 00:00:58,000
meer maklik te vind en op te los die probleem.

23
00:00:58,000 --> 00:01:01,000
Valgrind ook verslae oor minder dodelike geheue,

24
00:01:01,000 --> 00:01:04,000
soos geheue lekkasies, die toekenning van hoop geheue,

25
00:01:04,000 --> 00:01:07,000
en vergeet om dit te bevry.

26
00:01:07,000 --> 00:01:10,000
Soos ons samesteller, klang, in ons debugger, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind is gratis sagteware, en dit is op die toestel geïnstalleer.

28
00:01:14,000 --> 00:01:16,000
Valgrind loop op jou program uitvoerbaar,

29
00:01:16,000 --> 00:01:20,000
nie jou C of h bron kode lêers,

30
00:01:20,000 --> 00:01:23,000
so wees seker dat jy 'n up-to-date kopie van jou program saamgestel

31
00:01:23,000 --> 00:01:25,000
met behulp van kletteren of maak.

32
00:01:25,000 --> 00:01:28,000
Dan kan die bestuur van jou program onder Valgrind

33
00:01:28,000 --> 00:01:32,000
so eenvoudig as net die standaard program bevel met die woord Valgrind prefixing,

34
00:01:32,000 --> 00:01:35,000
wat begin op Valgrind en hardloop die program binnekant van dit.

35
00:01:35,000 --> 00:01:38,000
Wanneer jy begin, Valgrind sommige komplekse

36
00:01:38,000 --> 00:01:41,000
jiggering die uitvoer op te stel vir die geheue tjeks,

37
00:01:41,000 --> 00:01:44,000
sodat dit kan 'n bietjie te kry up and running.

38
00:01:44,000 --> 00:01:48,000
Die program sal dan normaalweg voer, word dit baie stadiger,

39
00:01:48,000 --> 00:01:52,000
en wanneer dit afwerkings, sal Valgrind print 'n opsomming van sy geheue gebruik.

40
00:01:52,000 --> 00:01:58,000
As alles goed gaan, sal dit lyk iets soos hierdie:

41
00:01:58,000 --> 00:02:01,000
In hierdie geval, / clean_program.

42
00:02:01,000 --> 00:02:04,000
is die pad na die program wat ek wil uit te voer.

43
00:02:04,000 --> 00:02:06,000
En terwyl hierdie een nie enige argumente,

44
00:02:06,000 --> 00:02:09,000
indien dit gedoen het Ek wil net ryg hulle op die einde van die opdrag soos gewoonlik.

45
00:02:09,000 --> 00:02:12,000
Clean program is net 'n dom klein program wat ek gemaak het

46
00:02:12,000 --> 00:02:15,000
wat ken ruimte vir 'n blok van ints op die hoop,

47
00:02:15,000 --> 00:02:19,000
sit 'n paar waardes binnekant van hulle, en bevry die hele blok.

48
00:02:19,000 --> 00:02:23,000
Dit is wat jy skiet, geen foute en geen lekkasies.

49
00:02:23,000 --> 00:02:27,000
>> Nog 'n belangrike maatstaf is die totale aantal grepe wat toegeken.

50
00:02:27,000 --> 00:02:32,000
Afhangende van die program, indien u toekennings is in die megagrepe of hoër,

51
00:02:32,000 --> 00:02:34,000
is jy waarskynlik doen iets verkeerd.

52
00:02:34,000 --> 00:02:37,000
Is jy onnodig stoor duplikate?

53
00:02:37,000 --> 00:02:40,000
Is jy met behulp van die hoop vir die stoor, wanneer dit beter sou wees om die stapel te gebruik?

54
00:02:40,000 --> 00:02:43,000
Dus, kan die geheue foute werklik kwaad.

55
00:02:43,000 --> 00:02:46,000
Die meer openlike skouspelagtige ineenstortings veroorsaak,

56
00:02:46,000 --> 00:02:49,000
maar selfs dan kan dit nog steeds moeilik wees om vas te stel

57
00:02:49,000 --> 00:02:51,000
wat presies tot die ongeluk gelei het.

58
00:02:51,000 --> 00:02:54,000
Meer slinkse wyse, 'n program met 'n geheue fout

59
00:02:54,000 --> 00:02:56,000
kan nog steeds skoon stel

60
00:02:56,000 --> 00:02:58,000
en kan nog steeds blyk korrek te werk

61
00:02:58,000 --> 00:03:01,000
omdat jy gelukkig die meeste van die tyd te kry.

62
00:03:01,000 --> 00:03:04,000
Na 'n paar "suksesvolle uitkomste,"

63
00:03:04,000 --> 00:03:07,000
jy mag dalk net dink dat 'n ongeluk is 'n gelukskoot van die rekenaar,

64
00:03:07,000 --> 00:03:10,000
maar die rekenaar is nooit verkeerd nie.

65
00:03:10,000 --> 00:03:13,000
>> Running Valgrind kan jou help om die oorsaak van sigbare geheue foute opspoor

66
00:03:13,000 --> 00:03:18,000
sowel as loer foute jy selfs nog nie weet nie.

67
00:03:18,000 --> 00:03:22,000
Elke keer Valgrind ontdek 'n probleem is, is dit druk inligting oor wat dit waargeneem.

68
00:03:22,000 --> 00:03:24,000
Elke item is redelik kortaf -

69
00:03:24,000 --> 00:03:27,000
die bron lyn van die gewraakte onderrig, wat die probleem is,

70
00:03:27,000 --> 00:03:30,000
en 'n bietjie inligting oor die geheue wat betrokke is -

71
00:03:30,000 --> 00:03:34,000
maar dikwels is dit genoeg inligting om jou aandag te rig op die regte plek.

72
00:03:34,000 --> 00:03:37,000
Hier is 'n voorbeeld van Valgrind loop op 'n buggy program

73
00:03:37,000 --> 00:03:40,000
wat nie 'n ongeldige lees van hoop geheue.

74
00:03:40,000 --> 00:03:49,000
Ons sien geen foute of waarskuwings in die samestelling.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, die fout opsomming sê dat daar twee foute -

76
00:03:53,000 --> 00:03:56,000
twee ongeldig gelees van grootte 4 - bytes, dit is.

77
00:03:56,000 --> 00:04:01,000
Slegtes sowel lees plaasgevind het in die hooffunksie van invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
die eerste on line 16 en die tweede on line 19.

79
00:04:04,000 --> 00:04:06,000
Kom ons kyk na die kode.

80
00:04:06,000 --> 00:04:11,000
Lyk soos die eerste oproep tot printf probeer een int verby die einde van ons geheue blok te lees.

81
00:04:11,000 --> 00:04:13,000
As ons terugkyk op Valgrind se uitset,

82
00:04:13,000 --> 00:04:16,000
sien ons dat Valgrind vertel ons presies dit.

83
00:04:16,000 --> 00:04:19,000
Begin die adres wat ons probeer om te lees 0 bytes

84
00:04:19,000 --> 00:04:22,000
verby die einde van die blok van grootte 16 bytes -

85
00:04:22,000 --> 00:04:25,000
vier 32-bis ints dat ons toegeken.

86
00:04:25,000 --> 00:04:29,000
Dit is die adres wat ons probeer om te lees begin reg aan die einde van ons blok,

87
00:04:29,000 --> 00:04:32,000
net soos ons sien in ons slegte printf oproep.

88
00:04:32,000 --> 00:04:36,000
Nou, kan ongeldig gelees nie lyk dat die groot van 'n deal,

89
00:04:36,000 --> 00:04:39,000
maar as jy die gebruik van daardie data om die vloei te beheer van jou program -

90
00:04:39,000 --> 00:04:42,000
byvoorbeeld, as deel van 'n IF-stelling of lus -

91
00:04:42,000 --> 00:04:45,000
dan kan dinge stil gaan sleg.

92
00:04:45,000 --> 00:04:47,000
Kyk hoe ek dit kan die invalid_read program hardloop

93
00:04:47,000 --> 00:04:50,000
en niks uit die gewone gebeur.

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

95
00:04:52,000 --> 00:04:56,000
>> Nou, laat ons kyk na 'n paar meer soorte foute wat jy kan teëkom in jou kode,

96
00:04:56,000 --> 00:04:59,000
en ons sal sien hoe Valgrind ontdek hulle.

97
00:04:59,000 --> 00:05:01,000
Ons het net gesien 'n voorbeeld van 'n invalid_read,

98
00:05:01,000 --> 00:05:04,000
so laat ons nou kyk na 'n invalid_write.

99
00:05:04,000 --> 00:05:09,000
Weereens, geen foute of waarskuwings in die samestelling.

100
00:05:09,000 --> 00:05:12,000
Okay, Valgrind sê dat daar twee foute in hierdie program -

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

102
00:05:15,000 --> 00:05:18,000
Kom check hierdie kode.

103
00:05:18,000 --> 00:05:21,000
Lyk my ons het 'n geval van die klassieke strlen plus een fout.

104
00:05:21,000 --> 00:05:24,000
Die kode nie malloc 'n ekstra greep van die ruimte

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

106
00:05:26,000 --> 00:05:30,000
so wanneer str kopie het om dit te skryf ssubstrlen "cs50 rotse!"

107
00:05:30,000 --> 00:05:33,000
dit het geskryf 1 byte verby die einde van die blok.

108
00:05:33,000 --> 00:05:36,000
Die invalid_read kom wanneer ons ons oproep om printf.

109
00:05:36,000 --> 00:05:40,000
Printf beland ongeldig geheue te lees wanneer dit lees / 0 karakter

110
00:05:40,000 --> 00:05:43,000
as dit lyk aan die einde van hierdie E-string is dit druk.

111
00:05:43,000 --> 00:05:45,000
Maar geeneen van hierdie ontsnap Valgrind.

112
00:05:45,000 --> 00:05:48,000
Sien ons dat dit gevang die invalid_write as deel van die str afskrif

113
00:05:48,000 --> 00:05:51,000
on line 11 van die hoof, en die invalid_read is deel van printf.

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

115
00:05:54,000 --> 00:05:57,000
Weereens, kan dit nie lyk soos 'n groot deal.

116
00:05:57,000 --> 00:06:00,000
Ons kan hierdie program oor en oor loop buite Valgrind

117
00:06:00,000 --> 00:06:03,000
en nie sien nie enige fout simptome.

118
00:06:03,000 --> 00:06:06,000
>> Maar, laat ons kyk na 'n effense variasie van hierdie om te sien

119
00:06:06,000 --> 00:06:09,000
hoe dinge kan kry regtig sleg is.

120
00:06:09,000 --> 00:06:14,000
So, toegestaan ​​word, is ons misbruik dinge meer as net 'n bietjie in hierdie kode.

121
00:06:14,000 --> 00:06:17,000
Ons is net die toekenning van ruimte op die hoop vir twee stringe

122
00:06:17,000 --> 00:06:19,000
die lengte van cs50 rotse,

123
00:06:19,000 --> 00:06:22,000
hierdie tyd, onthou die / 0 karakter.

124
00:06:22,000 --> 00:06:25,000
Maar dan moet ons gooi in 'n super-lang string in die geheue blok

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

126
00:06:27,000 --> 00:06:30,000
Watter effek sal dit op die geheue blok dat T punte?

127
00:06:30,000 --> 00:06:34,000
Wel, as T punte te geheue wat net aangrensend aan S,

128
00:06:34,000 --> 00:06:37,000
kom net nadat dit,

129
00:06:37,000 --> 00:06:39,000
dan kan ons geskryf het oor die deel van T.

130
00:06:39,000 --> 00:06:41,000
Kom ons gebruik hierdie kode.

131
00:06:41,000 --> 00:06:43,000
Kyk na wat gebeur het.

132
00:06:43,000 --> 00:06:47,000
Die stringe wat ons in ons hoop blokke beide gestoor verskyn het korrek uitgedruk.

133
00:06:47,000 --> 00:06:49,000
Dit lyk asof niks verkeerd is nie.

134
00:06:49,000 --> 00:06:52,000
Maar laat ons gaan terug in ons kode en

135
00:06:52,000 --> 00:06:55,000
kommentaar uit die lyn waar ons cs50 rotse kopieer

136
00:06:55,000 --> 00:06:59,000
in die tweede geheue blok, wys deur t.

137
00:06:59,000 --> 00:07:02,000
Nou, wanneer ons gebruik hierdie kode moet ons

138
00:07:02,000 --> 00:07:06,000
sien net die inhoud van die eerste geheue blok druk.

139
00:07:06,000 --> 00:07:09,000
Whoa, selfs al het ons nie str afskrif

140
00:07:09,000 --> 00:07:12,000
enige karakters in die tweede hoop blok, die een wys deur T,

141
00:07:12,000 --> 00:07:15,000
kry ons 'n druk uit.

142
00:07:15,000 --> 00:07:18,000
Trouens, die tou wat ons in ons eerste blok gestop

143
00:07:18,000 --> 00:07:21,000
oorrompel die eerste blok en in die tweede blokkie,

144
00:07:21,000 --> 00:07:23,000
maak alles lyk normaal.

145
00:07:23,000 --> 00:07:26,000
Valgrind, maar, vertel die ware verhaal.

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

147
00:07:28,000 --> 00:07:32,000
Al dié ongeldig lees en skryf.

148
00:07:32,000 --> 00:07:36,000
>> Kom ons kyk na 'n voorbeeld van 'n ander soort van fout.

149
00:07:36,000 --> 00:07:39,000
Hier het ons iets doen nogal jammer.

150
00:07:39,000 --> 00:07:41,000
Ons gryp ruimte vir 'n int op die hoop,

151
00:07:41,000 --> 00:07:45,000
en ons inisialiseer 'n int pointer - p - om te verwys na daardie ruimte.

152
00:07:45,000 --> 00:07:48,000
Maar, terwyl ons wyser is geïnisialiseer word,

153
00:07:48,000 --> 00:07:52,000
die data dat dit verwys na net watter gemors is in daardie deel van die hoop.

154
00:07:52,000 --> 00:07:55,000
So wanneer ons laai dat die data in int i,

155
00:07:55,000 --> 00:07:57,000
ons tegnies inisialiseer i,

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

157
00:08:00,000 --> 00:08:03,000
Die oproep om te beweer, wat is 'n handige debugging makro

158
00:08:03,000 --> 00:08:06,000
omskryf in die welverdiende naam beweer biblioteek,

159
00:08:06,000 --> 00:08:09,000
sal staak die program as sy toets toestand misluk.

160
00:08:09,000 --> 00:08:11,000
Dit is, as ek is nie 0.

161
00:08:11,000 --> 00:08:14,000
Afhangende van wat was in die hoop ruimte, wys deur p,

162
00:08:14,000 --> 00:08:18,000
hierdie program kan soms werk en versuim om op ander tye.

163
00:08:18,000 --> 00:08:20,000
As dit werk, ons is maar net gelukkig.

164
00:08:20,000 --> 00:08:24,000
Die opsteller sal nie hierdie fout vang, maar sal seker Valgrind.

165
00:08:24,000 --> 00:08:28,000
Daar sien ons die fout wat spruit uit die gebruik van daardie junk data.

166
00:08:28,000 --> 00:08:32,000
>> Wanneer jy toeken hoopgeheue, maar deallocate dit nie of vry,

167
00:08:32,000 --> 00:08:34,000
wat genoem word 'n lek.

168
00:08:34,000 --> 00:08:37,000
Vir 'n klein, kortstondige program wat loop en onmiddellik uitgange,

169
00:08:37,000 --> 00:08:39,000
lekkasies is redelik skadeloos,

170
00:08:39,000 --> 00:08:42,000
maar vir 'n projek van die groter grootte en / of lang lewe,

171
00:08:42,000 --> 00:08:46,000
selfs 'n klein lek kan vererger in iets groot.

172
00:08:46,000 --> 00:08:49,000
Vir CS50, verwag ons om jou te

173
00:08:49,000 --> 00:08:51,000
sorg bevry van al van die hoop, geheue wat jy toeken,

174
00:08:51,000 --> 00:08:54,000
omdat ons wil hê dat jy die vaardighede op te bou om behoorlik die handleiding proses hanteer

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

176
00:08:56,000 --> 00:08:59,000
Om dit te doen, moet jy jou program 'n presiese

177
00:08:59,000 --> 00:09:03,000
een-tot-een korrespondensie tussen malloc en gratis oproepe.

178
00:09:03,000 --> 00:09:06,000
Gelukkig kan Valgrind u help met die geheue lekkasies.

179
00:09:06,000 --> 00:09:09,000
Hier is 'n lekkende program genaamd leak.c wat ken

180
00:09:09,000 --> 00:09:13,000
ruimte op die hoop, om dit te skryf, maar nie vry om dit.

181
00:09:13,000 --> 00:09:16,000
Ons stel dit met Maak en hardloop onder Valgrind,

182
00:09:16,000 --> 00:09:18,000
en ons sien dat, terwyl ons het geen geheue foute,

183
00:09:18,000 --> 00:09:20,000
ons het 'n lek.

184
00:09:20,000 --> 00:09:23,000
Daar is 16 bytes beslis verlore,

185
00:09:23,000 --> 00:09:27,000
wat beteken dat die wyser na daardie geheue was nie in omvang toe die program opgewonde.

186
00:09:27,000 --> 00:09:30,000
Nou, Valgrind nie gee ons 'n ton van die inligting oor die lekkasie,

187
00:09:30,000 --> 00:09:35,000
maar as ons hierdie klein daarop dat dit gee af na die onderkant van sy verslag

188
00:09:35,000 --> 00:09:38,000
rerun met - lek-check = volle

189
00:09:38,000 --> 00:09:41,000
die volle besonderhede van die geheue gelek te sien,

190
00:09:41,000 --> 00:09:44,000
ons kry meer inligting.

191
00:09:44,000 --> 00:09:46,000
Nou, in die hoop opsomming,

192
00:09:46,000 --> 00:09:50,000
Valgrind vertel ons waar die geheue wat verlore was aanvanklik toegeken.

193
00:09:50,000 --> 00:09:52,000
Net soos ons weet uit te kyk in die bronkode,

194
00:09:52,000 --> 00:09:55,000
Valgrind weet ons dat ons die geheue gelek

195
00:09:55,000 --> 00:09:58,000
toegeken met 'n oproep tot malloc on line 8 van leak.c

196
00:09:58,000 --> 00:10:00,000
in die hooffunksie.

197
00:10:00,000 --> 00:10:02,000
Pretty nifty.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind kategoriseer lekkasies deur gebruik te maak van hierdie terme:

199
00:10:04,000 --> 00:10:07,000
Beslis verloor - dit is 'n hoop toegeken geheue

200
00:10:07,000 --> 00:10:10,000
wat die program het nie meer 'n wyser.

201
00:10:10,000 --> 00:10:14,000
Valgrind weet dat jy eens gehad het die wyser, maar het sedertdien verlore spoor van dit.

202
00:10:14,000 --> 00:10:17,000
Hierdie geheue is beslis uitgelek het.

203
00:10:17,000 --> 00:10:20,000
Indirek verloor - dit is 'n hoop toegeken geheue

204
00:10:20,000 --> 00:10:24,000
wat die enigste verwysings na dit ook verlore.

205
00:10:24,000 --> 00:10:27,000
Byvoorbeeld, as jy verloor jou muis na die eerste nodus van 'n geskakelde lys,

206
00:10:27,000 --> 00:10:30,000
dan is die eerste node self sal beslis verlore gaan,

207
00:10:30,000 --> 00:10:34,000
terwyl enige daaropvolgende nodes sou indirek verlore wees.

208
00:10:34,000 --> 00:10:37,000
Moontlik verloor - dit is 'n hoop toegeken geheue

209
00:10:37,000 --> 00:10:41,000
waarin Valgrind nie seker kan wees of daar is 'n aanwyser of nie.

210
00:10:41,000 --> 00:10:44,000
Nog bereikbaar is hoop toegeken geheue

211
00:10:44,000 --> 00:10:47,000
wat die program nog 'n wyser by die uitgang,

212
00:10:47,000 --> 00:10:50,000
wat beteken gewoonlik dat 'n globale veranderlike dui daarop.

213
00:10:50,000 --> 00:10:53,000
Om te kyk vir hierdie lekkasies, sal jy ook die opsie om te sluit

214
00:10:53,000 --> 00:10:55,000
- Nog bereikbaar = ja

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

216
00:10:58,000 --> 00:11:01,000
>> Hierdie verskillende gevalle kan vereis verskillende strategieë vir die skoonmaak van hulle,

217
00:11:01,000 --> 00:11:05,000
maar lekkasies moet uitgeskakel word.

218
00:11:05,000 --> 00:11:08,000
Ongelukkig kan tot vaststelling van lekkasies moeilik wees om dit te doen,

219
00:11:08,000 --> 00:11:11,000
aangesien verkeerde oproepe gratis kan blaas jou program.

220
00:11:11,000 --> 00:11:14,000
Byvoorbeeld, as ons kyk by invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
sien ons 'n voorbeeld van slegte geheue deallocation.

222
00:11:18,000 --> 00:11:21,000
Wat moet 'n enkele oproep om die hele blok te bevry

223
00:11:21,000 --> 00:11:24,000
geheue verwys na deur int_block,

224
00:11:24,000 --> 00:11:27,000
het eerder 'n poging om elke int-grootte artikel te bevry

225
00:11:27,000 --> 00:11:29,000
van die geheue individueel.

226
00:11:29,000 --> 00:11:32,000
Dit sal katastrofaal misluk.

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

228
00:11:34,000 --> 00:11:36,000
Dit is beslis nie goed nie.

229
00:11:36,000 --> 00:11:39,000
As jy vas met hierdie soort van fout, al is, en jy weet nie waar om te kyk,

230
00:11:39,000 --> 00:11:41,000
om terug te val op jou nuwe beste vriend.

231
00:11:41,000 --> 00:11:44,000
Jy het reg geraai - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, soos altyd, weet presies wat is.

233
00:11:47,000 --> 00:11:50,000
Die alloc en gratis tellings stem nie ooreen nie.

234
00:11:50,000 --> 00:11:52,000
Ons het 1 alloc en 4 FreeS.

235
00:11:52,000 --> 00:11:55,000
En Valgrind vertel ons ook waar die eerste slegte gratis oproep -

236
00:11:55,000 --> 00:11:58,000
die een wat aanleiding tot die Perspectief aanpassen - is afkomstig van -

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

238
00:12:00,000 --> 00:12:03,000
Soos jy kan sien, slegte oproepe te bevry is regtig sleg,

239
00:12:03,000 --> 00:12:05,000
Daarom raai ons jou laat jou program lek

240
00:12:05,000 --> 00:12:08,000
terwyl jy werk om die funksie korrek is.

241
00:12:08,000 --> 00:12:12,000
Begin soek vir lekkasies slegs nadat jou program korrek werk nie,

242
00:12:12,000 --> 00:12:14,000
sonder enige ander foute.

243
00:12:14,000 --> 00:12:16,000
>> En dit is al wat ons gekry het vir hierdie video.

244
00:12:16,000 --> 00:12:18,000
Nou wat is jy wag vir?

245
00:12:18,000 --> 00:12:21,000
Gaan loop Valgrind op jou programme nou.

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