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, Universitatea Harvard]

3
00:00:05,000 --> 00:00:07,000
Acest lucru este CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
Unele dintre cele mai dificile bug-uri în programele C

5
00:00:10,000 --> 00:00:13,000
provin din proasta gestionare a memoriei.

6
00:00:13,000 --> 00:00:15,000
Există un număr foarte mare de moduri de a șurub lucrurile,

7
00:00:15,000 --> 00:00:17,000
inclusiv alocarea sumei greșit de memorie,

8
00:00:17,000 --> 00:00:20,000
uitând pentru a inițializa variabile,

9
00:00:20,000 --> 00:00:23,000
scris, înainte sau după încheierea unui tampon,

10
00:00:23,000 --> 00:00:25,000
și eliberarea de memorie păstreze ori mai multe.

11
00:00:25,000 --> 00:00:28,000
Simptomele variaza de la accidente intermitente

12
00:00:28,000 --> 00:00:30,000
la valori misterios adăugiri,

13
00:00:30,000 --> 00:00:34,000
de multe ori la locurile și orele foarte îndepărtate de eroare original.

14
00:00:34,000 --> 00:00:37,000
Trasarea problema observată înapoi la cauza rădăcină care stau la baza

15
00:00:37,000 --> 00:00:39,000
poate fi o provocare,

16
00:00:39,000 --> 00:00:42,000
dar din fericire exista un program de ajutor numit Valgrind

17
00:00:42,000 --> 00:00:44,000
care pot face o mulțime de a ajuta.

18
00:00:44,000 --> 00:00:47,000
>> Tu conduci un program în cadrul Valgrind pentru a permite

19
00:00:47,000 --> 00:00:50,000
verificarea largă de alocări de memorie heap și căi de acces.

20
00:00:50,000 --> 00:00:53,000
Atunci când detectează o problemă Valgrind, îți dă imediat,

21
00:00:53,000 --> 00:00:56,000
informații directe că vă permite să

22
00:00:56,000 --> 00:00:58,000
mai ușor găsi și repara problema.

23
00:00:58,000 --> 00:01:01,000
Valgrind, de asemenea, rapoarte privind probleme de memorie mai puțin mortale,

24
00:01:01,000 --> 00:01:04,000
cum ar fi pierderi de memorie, alocarea de memorie heap,

25
00:01:04,000 --> 00:01:07,000
și uitând să-l elibereze.

26
00:01:07,000 --> 00:01:10,000
Vrei nostru compilator, zăngănit, în depanator noastră, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind este software liber, și este instalat pe aparat.

28
00:01:14,000 --> 00:01:16,000
Valgrind rulează pe executabil binar dumneavoastră,

29
00:01:16,000 --> 00:01:20,000
nu-ți c sau. h fișiere. cod sursă,

30
00:01:20,000 --> 00:01:23,000
astfel încât să fie sigur că va fi compilat o copie up-to-data de programul tău

31
00:01:23,000 --> 00:01:25,000
folosind zăngănit sau fac.

32
00:01:25,000 --> 00:01:28,000
Apoi, execută programul în cadrul Valgrind poate fi

33
00:01:28,000 --> 00:01:32,000
la fel de simplu ca și prefixarea doar comanda programul standard cu Valgrind cuvântul,

34
00:01:32,000 --> 00:01:35,000
care începe Valgrind și rulează programul în interiorul său.

35
00:01:35,000 --> 00:01:38,000
Atunci când începe, Valgrind face unele complexe

36
00:01:38,000 --> 00:01:41,000
manipulăm pentru a configura executabil pentru controalele de memorie,

37
00:01:41,000 --> 00:01:44,000
asa ca poate dura un pic să se ridice și să fie difuzate.

38
00:01:44,000 --> 00:01:48,000
Programul va executa în mod normal, atunci, fie că este vorba de mult mai lent,

39
00:01:48,000 --> 00:01:52,000
și când se termină, Valgrind va imprima un rezumat de utilizare a memoriei sale.

40
00:01:52,000 --> 00:01:58,000
Dacă totul merge bine, va arata ceva de genul asta:

41
00:01:58,000 --> 00:02:01,000
În acest caz, / clean_program.

42
00:02:01,000 --> 00:02:04,000
este calea către programul vreau să fug.

43
00:02:04,000 --> 00:02:06,000
Și în timp ce aceasta nu ia nici un argument,

44
00:02:06,000 --> 00:02:09,000
în cazul în care a făcut-o aș doar le calul pe la sfarsitul comenzii ca de obicei.

45
00:02:09,000 --> 00:02:12,000
Programul Clean este doar un program de prostuță mic am creat

46
00:02:12,000 --> 00:02:15,000
care alocă spațiu pentru un bloc de Ints pe heap,

47
00:02:15,000 --> 00:02:19,000
pune niste valori din interiorul ei, și eliberează tot blocul.

48
00:02:19,000 --> 00:02:23,000
Aceasta este ceea ce filmarile pentru, nu există erori și fără scurgeri.

49
00:02:23,000 --> 00:02:27,000
>> Un alt parametru important este numărul total de octeți alocate.

50
00:02:27,000 --> 00:02:32,000
În funcție de program, în cazul în care alocările dvs. sunt în megaocteți sau mai mare,

51
00:02:32,000 --> 00:02:34,000
faci, probabil, ceva gresit.

52
00:02:34,000 --> 00:02:37,000
Ești stocarea inutil dubluri?

53
00:02:37,000 --> 00:02:40,000
Ești folosind heap pentru depozitare, atunci când ar fi mai bine pentru a utiliza stiva?

54
00:02:40,000 --> 00:02:43,000
Deci, erorile de memorie poate fi cu adevărat rău.

55
00:02:43,000 --> 00:02:46,000
Cele mai vizibile provoca accidente spectaculoase,

56
00:02:46,000 --> 00:02:49,000
dar chiar și atunci poate fi încă greu de identificat

57
00:02:49,000 --> 00:02:51,000
exact ceea ce a dus la accident.

58
00:02:51,000 --> 00:02:54,000
Mai insidios, un program cu o eroare de memorie

59
00:02:54,000 --> 00:02:56,000
poate compila în continuare curat

60
00:02:56,000 --> 00:02:58,000
și poate părea încă să funcționeze corect

61
00:02:58,000 --> 00:03:01,000
pentru că ați reușit să obțineți noroc cele mai multe ori.

62
00:03:01,000 --> 00:03:04,000
Dupa mai multe "rezultate de succes,"

63
00:03:04,000 --> 00:03:07,000
s-ar putea crede că tocmai un accident este o întâmplare de calculator,

64
00:03:07,000 --> 00:03:10,000
dar calculatorul nu este niciodată greșit.

65
00:03:10,000 --> 00:03:13,000
>> Rularea Valgrind poate ajuta să urmăriți în jos cauza unor erori de memorie vizibile

66
00:03:13,000 --> 00:03:18,000
precum și găsi ca spectatori erori pe care nici măcar nu știu încă despre.

67
00:03:18,000 --> 00:03:22,000
De fiecare dată când detectează o problemă Valgrind, se imprimă informații despre ceea ce observă.

68
00:03:22,000 --> 00:03:24,000
Fiecare element este destul de concis -

69
00:03:24,000 --> 00:03:27,000
linia sursa de instruire ofensatoare, ceea ce este problema,

70
00:03:27,000 --> 00:03:30,000
și un pic de informații despre memoria implicate -

71
00:03:30,000 --> 00:03:34,000
dar de multe ori e suficiente informații pentru a direcționa atenția spre locul potrivit.

72
00:03:34,000 --> 00:03:37,000
Aici este un exemplu de Valgrind rulează pe un program de buggy

73
00:03:37,000 --> 00:03:40,000
care face o citire invalid de memorie heap.

74
00:03:40,000 --> 00:03:49,000
Ne vedem nici o eroare sau avertismente în conturi.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, rezumatul eroare spune că există două erori -

76
00:03:53,000 --> 00:03:56,000
două citiri invalid de marimea 4 - octeți, care este.

77
00:03:56,000 --> 00:04:01,000
Atât de rău citește avut loc în funcția principală a invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
primul pe linia 16, iar al doilea pe linia 19.

79
00:04:04,000 --> 00:04:06,000
Să ne uităm la codul.

80
00:04:06,000 --> 00:04:11,000
Se pare ca primul apel pentru a printf încearcă să citească un int ultimile sfârșitul blocului memoriei noastre.

81
00:04:11,000 --> 00:04:13,000
Dacă ne uităm înapoi la puterea lui Valgrind,

82
00:04:13,000 --> 00:04:16,000
vom vedea că Valgrind ne-a spus exact acest lucru.

83
00:04:16,000 --> 00:04:19,000
Adresa încercăm să citească începe 0 bytes

84
00:04:19,000 --> 00:04:22,000
trecut la sfârșitul blocului de dimensiunea 16 bytes -

85
00:04:22,000 --> 00:04:25,000
patru 32-biți Ints pe care le alocate.

86
00:04:25,000 --> 00:04:29,000
Asta este, adresa am fost încercarea de a citi începe chiar de la sfârșitul blocului nostru,

87
00:04:29,000 --> 00:04:32,000
așa cum vedem în nostru apel printf rău.

88
00:04:32,000 --> 00:04:36,000
Acum, invalid citiri ar putea să nu pară atât de mare de o afacere,

89
00:04:36,000 --> 00:04:39,000
dar dacă utilizați aceste date pentru a controla fluxul de programul dumneavoastră -

90
00:04:39,000 --> 00:04:42,000
de exemplu, ca parte a unei if sau buclă -

91
00:04:42,000 --> 00:04:45,000
atunci lucrurile pot merge prost în tăcere.

92
00:04:45,000 --> 00:04:47,000
Uita-te la modul în care pot rula programul invalid_read

93
00:04:47,000 --> 00:04:50,000
și nimic ieșit din comun se întâmplă.

94
00:04:50,000 --> 00:04:52,000
Înfricoșător, nu-i asa?

95
00:04:52,000 --> 00:04:56,000
>> Acum, să ne uităm la unele tipuri de erori mai multe pe care le-ar putea întâlni în cod,

96
00:04:56,000 --> 00:04:59,000
și vom vedea cum Valgrind le detectează.

97
00:04:59,000 --> 00:05:01,000
Am văzut doar un exemplu de invalid_read,

98
00:05:01,000 --> 00:05:04,000
deci acum să verificați un invalid_write.

99
00:05:04,000 --> 00:05:09,000
Din nou, nu există erori sau avertismente în conturi.

100
00:05:09,000 --> 00:05:12,000
Bine, Valgrind spune că există două erori în acest program -

101
00:05:12,000 --> 00:05:15,000
și invalid_write și un invalid_read.

102
00:05:15,000 --> 00:05:18,000
Să verificăm acest cod.

103
00:05:18,000 --> 00:05:21,000
Se pare că avem o instanță a clasic strlen plus un bug.

104
00:05:21,000 --> 00:05:24,000
Codul nu malloc un octet suplimentar de spațiu

105
00:05:24,000 --> 00:05:26,000
pentru caracterul / 0,

106
00:05:26,000 --> 00:05:30,000
asa ca atunci cand str. copie a mers să-l scrie la ssubstrlen "CS50 pietre!"

107
00:05:30,000 --> 00:05:33,000
a scris 1 octet ultimile sfârșitul blocului nostru.

108
00:05:33,000 --> 00:05:36,000
Invalid_read vine atunci când vom face apelul nostru la printf.

109
00:05:36,000 --> 00:05:40,000
Printf se termină citirea de memorie invalidă când se citește / 0 caractere

110
00:05:40,000 --> 00:05:43,000
cum se pare, la sfârșitul acestui șir E e de imprimare.

111
00:05:43,000 --> 00:05:45,000
Dar nimic din toate astea scăpat Valgrind.

112
00:05:45,000 --> 00:05:48,000
Vedem că a prins-o invalid_write, ca parte a copiei str.

113
00:05:48,000 --> 00:05:51,000
pe linia 11 din principal, și invalid_read este parte a printf.

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

115
00:05:54,000 --> 00:05:57,000
Din nou, acest lucru nu s-ar putea părea ca o afacere mare.

116
00:05:57,000 --> 00:06:00,000
Ne poate rula acest program de peste si peste din afara Valgrind

117
00:06:00,000 --> 00:06:03,000
și nu văd nici un simptom de eroare.

118
00:06:03,000 --> 00:06:06,000
>> Cu toate acestea, să ne uităm la o ușoară variație a acestei pentru a vedea

119
00:06:06,000 --> 00:06:09,000
cum lucrurile pot deveni foarte rău.

120
00:06:09,000 --> 00:06:14,000
Deci, a acordat, suntem abuzează de lucruri mai mult decât doar un pic în acest cod.

121
00:06:14,000 --> 00:06:17,000
Suntem doar alocarea de spațiu pe heap pentru două șiruri

122
00:06:17,000 --> 00:06:19,000
lungimea CS50 roci,

123
00:06:19,000 --> 00:06:22,000
de data aceasta, amintindu-/ 0 caractere.

124
00:06:22,000 --> 00:06:25,000
Dar apoi am arunca într-un șir de super-lung în bloc de memorie

125
00:06:25,000 --> 00:06:27,000
că S este îndreptat spre.

126
00:06:27,000 --> 00:06:30,000
Ce efect va avea asupra faptul că blocul de memorie care punctele T la?

127
00:06:30,000 --> 00:06:34,000
Ei bine, în cazul în care punctele de T în memoria asta e doar adiacent la S,

128
00:06:34,000 --> 00:06:37,000
vine doar după ce,

129
00:06:37,000 --> 00:06:39,000
apoi ne-am fi scris peste o parte din T.

130
00:06:39,000 --> 00:06:41,000
Să rula acest cod.

131
00:06:41,000 --> 00:06:43,000
Uită-te la ceea ce sa întâmplat.

132
00:06:43,000 --> 00:06:47,000
Siruri de caractere am stocate în blocuri heap noastre ambele părea să fi imprimate corect.

133
00:06:47,000 --> 00:06:49,000
Nimic nu pare deloc greșit.

134
00:06:49,000 --> 00:06:52,000
Cu toate acestea, să mergem înapoi în codul nostru și

135
00:06:52,000 --> 00:06:55,000
comentați linia de unde am copiat CS50 roci

136
00:06:55,000 --> 00:06:59,000
în bloc a doua memorie, a subliniat de t.

137
00:06:59,000 --> 00:07:02,000
Acum, când vom rula acest cod ar trebui să ne

138
00:07:02,000 --> 00:07:06,000
doar vedea conținutul bloc de memorie prima imprima.

139
00:07:06,000 --> 00:07:09,000
Oau, chiar dacă nu am făcut-Str copie

140
00:07:09,000 --> 00:07:12,000
toate caracterele în bloc heap al doilea, cel indicat de T,

141
00:07:12,000 --> 00:07:15,000
vom obține o imprimare afară.

142
00:07:15,000 --> 00:07:18,000
Într-adevăr, șirul am umplute în bloc primul nostru

143
00:07:18,000 --> 00:07:21,000
depășit primul bloc și în al doilea bloc,

144
00:07:21,000 --> 00:07:23,000
face totul pare normal.

145
00:07:23,000 --> 00:07:26,000
Valgrind, deși, ne spune povestea adevarata.

146
00:07:26,000 --> 00:07:28,000
Acolo mergem.

147
00:07:28,000 --> 00:07:32,000
Toți cei invalid citește și scrie.

148
00:07:32,000 --> 00:07:36,000
>> Să ne uităm la un exemplu de un alt fel de eroare.

149
00:07:36,000 --> 00:07:39,000
Aici facem ceva destul de nefericit.

150
00:07:39,000 --> 00:07:41,000
Ne apuca spațiu pentru un int pe heap,

151
00:07:41,000 --> 00:07:45,000
și am inițializa un pointer int - p - pentru a indica acel spațiu.

152
00:07:45,000 --> 00:07:48,000
Cu toate acestea, în timp ce indicatorul nostru este inițializat,

153
00:07:48,000 --> 00:07:52,000
datele pe care se indică doar la a tot ce este gunoi, în acea parte a heap.

154
00:07:52,000 --> 00:07:55,000
Așa că atunci când am încărcați că datele în int i,

155
00:07:55,000 --> 00:07:57,000
am inițializa punct de vedere tehnic i,

156
00:07:57,000 --> 00:08:00,000
dar facem acest lucru cu date nesolicitate.

157
00:08:00,000 --> 00:08:03,000
Apel pentru a afirma, care este un macro de depanare la îndemână

158
00:08:03,000 --> 00:08:06,000
definite în aptly numit afirma bibliotecă,

159
00:08:06,000 --> 00:08:09,000
va abandona programul său în cazul în care condiția de testare nu reușește.

160
00:08:09,000 --> 00:08:11,000
Asta este, dacă nu este 0.

161
00:08:11,000 --> 00:08:14,000
În funcție de ceea ce a fost în spațiul grămadă, indicat de p,

162
00:08:14,000 --> 00:08:18,000
acest program ar putea să funcționeze, uneori, și nu în alte momente.

163
00:08:18,000 --> 00:08:20,000
Dacă funcționează, suntem abia la noroc.

164
00:08:20,000 --> 00:08:24,000
Compilatorul nu va prinde această eroare, dar Valgrind voința sigur.

165
00:08:24,000 --> 00:08:28,000
Acolo vedem eroarea care rezultă din utilizarea de către noi a acestor date nesolicitate.

166
00:08:28,000 --> 00:08:32,000
>> Când aloca memorie heap, dar nu-l dealoca sau gratuit aceasta,

167
00:08:32,000 --> 00:08:34,000
care este numit o scurgere.

168
00:08:34,000 --> 00:08:37,000
Pentru un mic, de scurtă durată, program care se execută imediat și ieșirile,

169
00:08:37,000 --> 00:08:39,000
scurgeri sunt destul de inofensive,

170
00:08:39,000 --> 00:08:42,000
dar pentru un proiect de dimensiuni mai mari și / sau de longevitate,

171
00:08:42,000 --> 00:08:46,000
chiar o scurgere mica poate combinate în ceva major.

172
00:08:46,000 --> 00:08:49,000
Pentru CS50, ne-aștept să

173
00:08:49,000 --> 00:08:51,000
grijă de a elibera toate memorie heap pe care le aloca,

174
00:08:51,000 --> 00:08:54,000
deoarece dorim să construiască abilitățile de a manevreze corect proces manual

175
00:08:54,000 --> 00:08:56,000
solicitate de către C.

176
00:08:56,000 --> 00:08:59,000
Pentru a face acest lucru, programul ar trebui să aibă o exacta

177
00:08:59,000 --> 00:09:03,000
unu-la-unu corespondenta între malloc și apeluri gratuite.

178
00:09:03,000 --> 00:09:06,000
Din fericire, Valgrind poate ajuta cu pierderi de memorie prea.

179
00:09:06,000 --> 00:09:09,000
Aici este un program de scurgeri numit leak.c care alocă

180
00:09:09,000 --> 00:09:13,000
spațiu pe heap, scrie el, dar nu-l elibera.

181
00:09:13,000 --> 00:09:16,000
Am compila cu Marca și rulați-l sub Valgrind,

182
00:09:16,000 --> 00:09:18,000
și vom vedea că, în timp ce noi nu au erori de memorie,

183
00:09:18,000 --> 00:09:20,000
avem o scurgere.

184
00:09:20,000 --> 00:09:23,000
Există 16 octeți cu siguranta pierdere,

185
00:09:23,000 --> 00:09:27,000
ceea ce înseamnă că indicatorul pentru ca memoria nu a fost în domeniul de aplicare atunci când programul ieșit.

186
00:09:27,000 --> 00:09:30,000
Acum, Valgrind nu ne oferă o tona de informatii despre scurgere,

187
00:09:30,000 --> 00:09:35,000
dar dacă urmăm această notă mică pe care-l dă jos spre partea de jos a raportului său

188
00:09:35,000 --> 00:09:38,000
să rulați din nou cu - scurgeri de check-= completă

189
00:09:38,000 --> 00:09:41,000
pentru a vedea detaliile complete ale memoriei scurgeri,

190
00:09:41,000 --> 00:09:44,000
vom obține mai multe informații.

191
00:09:44,000 --> 00:09:46,000
Acum, în rezumat heap,

192
00:09:46,000 --> 00:09:50,000
Valgrind ne spune în cazul în care memoria, care a fost pierdut a fost alocat inițial.

193
00:09:50,000 --> 00:09:52,000
Așa cum știm din căutați în codul sursă,

194
00:09:52,000 --> 00:09:55,000
Valgrind ne informează că am scurs de memorie

195
00:09:55,000 --> 00:09:58,000
alocate cu un apel la malloc pe linia 8 din leak.c

196
00:09:58,000 --> 00:10:00,000
în funcția de principal.

197
00:10:00,000 --> 00:10:02,000
Destul de puturos.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind clasifică scurgeri folosind acești termeni:

199
00:10:04,000 --> 00:10:07,000
Categoric pierdere - aceasta este o memorie heap alocată

200
00:10:07,000 --> 00:10:10,000
la care programul nu mai are un pointer.

201
00:10:10,000 --> 00:10:14,000
Valgrind știe că ați avut o dată, dar au pierdut indicatorul, deoarece pista de ea.

202
00:10:14,000 --> 00:10:17,000
Această memorie este cu siguranta scurgeri.

203
00:10:17,000 --> 00:10:20,000
Indirect pierdere - aceasta este o memorie heap alocată

204
00:10:20,000 --> 00:10:24,000
la care indicii doar să-l, de asemenea, sunt pierdute.

205
00:10:24,000 --> 00:10:27,000
De exemplu, dacă ți-ai pierdut indicatorul pentru primul nod al unei liste legate,

206
00:10:27,000 --> 00:10:30,000
apoi primul nod în sine ar fi cu siguranta pierdut,

207
00:10:30,000 --> 00:10:34,000
în timp ce orice noduri ulterioare ar fi în mod indirect pierdut.

208
00:10:34,000 --> 00:10:37,000
Posibil pierdut - aceasta este o memorie heap alocată

209
00:10:37,000 --> 00:10:41,000
la care Valgrind nu poate fi sigur dacă există un pointer sau nu.

210
00:10:41,000 --> 00:10:44,000
Încă realizabil este memoria heap alocată

211
00:10:44,000 --> 00:10:47,000
la care programul are încă un pointer la ieșire,

212
00:10:47,000 --> 00:10:50,000
care de obicei înseamnă că o variabilă de puncte la nivel mondial la ea.

213
00:10:50,000 --> 00:10:53,000
Pentru a verifica aceste scurgeri, veți avea, de asemenea, să includă opțiunea

214
00:10:53,000 --> 00:10:55,000
- Încă-accesibil = da

215
00:10:55,000 --> 00:10:58,000
în invocarea dvs. de Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Aceste cazuri diferite ar putea necesita strategii diferite pentru curățarea le,

217
00:11:01,000 --> 00:11:05,000
dar scurgeri ar trebui eliminate.

218
00:11:05,000 --> 00:11:08,000
Din păcate, de stabilire scurgeri poate fi greu să facă,

219
00:11:08,000 --> 00:11:11,000
deoarece apelurile către incorecte free se mai poate arunca în aer programul tău.

220
00:11:11,000 --> 00:11:14,000
De exemplu, dacă ne uităm la invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
vom vedea un exemplu de Dealocarea memorie proasta.

222
00:11:18,000 --> 00:11:21,000
Ce ar trebui să fie un singur apel pentru a elibera întregul bloc

223
00:11:21,000 --> 00:11:24,000
de memorie indicat de către int_block,

224
00:11:24,000 --> 00:11:27,000
în schimb a devenit o încercare de a elibera fiecare secțiune int-urilor

225
00:11:27,000 --> 00:11:29,000
de memorie în mod individual.

226
00:11:29,000 --> 00:11:32,000
Acest lucru va eșua catastrofal.

227
00:11:32,000 --> 00:11:34,000
Boom! Ce o eroare.

228
00:11:34,000 --> 00:11:36,000
Acest lucru nu este cu siguranta bine.

229
00:11:36,000 --> 00:11:39,000
Dacă te-ai blocat cu acest tip de eroare, deși, și nu știi unde să te uiți,

230
00:11:39,000 --> 00:11:41,000
cădea înapoi pe prietenul tau cel mai bun nou.

231
00:11:41,000 --> 00:11:44,000
Ai ghicit - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, ca întotdeauna, știe exact ce sa întâmplat.

233
00:11:47,000 --> 00:11:50,000
Contează alloc si gratuit nu se potrivesc.

234
00:11:50,000 --> 00:11:52,000
Avem 1 și 4 alloc eliberează.

235
00:11:52,000 --> 00:11:55,000
Și, de asemenea, Valgrind ne spune în cazul în care primul apel gratuit rău -

236
00:11:55,000 --> 00:11:58,000
cel care a declanșat Blowup - vine de la -

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

238
00:12:00,000 --> 00:12:03,000
După cum vedeți, solicită să-i elibereze rele sunt într-adevăr rău,

239
00:12:03,000 --> 00:12:05,000
așa că vă recomandăm închirierea scurgere de program

240
00:12:05,000 --> 00:12:08,000
în timp ce lucrați pe obtinerea funcționalitatea corectă.

241
00:12:08,000 --> 00:12:12,000
Începe căutarea pentru scurgeri numai după ce programul dvs. este de lucru în mod corespunzător,

242
00:12:12,000 --> 00:12:14,000
fără alte erori.

243
00:12:14,000 --> 00:12:16,000
>> Și asta e tot ce avem pentru acest videoclip.

244
00:12:16,000 --> 00:12:18,000
Acum, ce mai aștepți?

245
00:12:18,000 --> 00:12:21,000
Du-te rula Valgrind pentru programele dvs. acum.

246
00:12:21,000 --> 00:12:25,000
Numele meu este Nate Hardison. Acest lucru este CS50. [CS50.TV]