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
Questo è CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
Alcuni dei bug più difficili programmi C

5
00:00:10,000 --> 00:00:13,000
provengono dalla cattiva gestione della memoria.

6
00:00:13,000 --> 00:00:15,000
Ci sono un numero enorme di modi per pasticci

7
00:00:15,000 --> 00:00:17,000
tra cui l'assegnazione della quantità errata di memoria,

8
00:00:17,000 --> 00:00:20,000
dimenticare di inizializzare le variabili,

9
00:00:20,000 --> 00:00:23,000
scritte prima o dopo la fine di un tampone,

10
00:00:23,000 --> 00:00:25,000
e liberando mantenere i tempi di memoria più.

11
00:00:25,000 --> 00:00:28,000
I sintomi variano da blocchi intermittenti

12
00:00:28,000 --> 00:00:30,000
ai valori misteriosamente scritti sopra,

13
00:00:30,000 --> 00:00:34,000
spesso in luoghi e tempi lontani da l'errore originale.

14
00:00:34,000 --> 00:00:37,000
Tracciare il problema osservato torna la causa principale di fondo

15
00:00:37,000 --> 00:00:39,000
può essere impegnativo,

16
00:00:39,000 --> 00:00:42,000
ma per fortuna c'è un programma utile chiamato Valgrind

17
00:00:42,000 --> 00:00:44,000
che può fare molto per aiutare.

18
00:00:44,000 --> 00:00:47,000
>> Si esegue un programma in Valgrind per consentire

19
00:00:47,000 --> 00:00:50,000
controllo esteso di allocazioni di memoria heap e accessi.

20
00:00:50,000 --> 00:00:53,000
Quando Valgrind rileva un problema, ti dà immediato,

21
00:00:53,000 --> 00:00:56,000
informazione diretta che consente di

22
00:00:56,000 --> 00:00:58,000
più facile trovare e risolvere il problema.

23
00:00:58,000 --> 00:01:01,000
Valgrind anche relazioni su problemi di memoria meno mortali,

24
00:01:01,000 --> 00:01:04,000
come ad esempio perdite di memoria, l'allocazione di memoria heap,

25
00:01:04,000 --> 00:01:07,000
e dimenticando per liberarlo.

26
00:01:07,000 --> 00:01:10,000
Come il nostro compilatore, Clang, nel nostro debugger, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind è software libero, e si è installato l'apparecchio.

28
00:01:14,000 --> 00:01:16,000
Valgrind viene eseguito sul binario eseguibile,

29
00:01:16,000 --> 00:01:20,000
non è il tuo. co. h file di codice sorgente,

30
00:01:20,000 --> 00:01:23,000
in modo da essere sicuro di aver compilato un up-to-data copia del programma

31
00:01:23,000 --> 00:01:25,000
usando Clang O Fai.

32
00:01:25,000 --> 00:01:28,000
Quindi, l'esecuzione del programma in Valgrind può essere

33
00:01:28,000 --> 00:01:32,000
semplice come solo anteponendo il comando standard di programma con il Valgrind parola,

34
00:01:32,000 --> 00:01:35,000
che avvia Valgrind ed esegue il programma all'interno di esso.

35
00:01:35,000 --> 00:01:38,000
Quando si avvia, fa un po 'complessa Valgrind

36
00:01:38,000 --> 00:01:41,000
jiggering per configurare il file eseguibile per le verifiche di memoria,

37
00:01:41,000 --> 00:01:44,000
in modo che possa prendere un po 'per ottenere installato e funzionante.

38
00:01:44,000 --> 00:01:48,000
Il programma sarà poi eseguito normalmente, sia molto più lentamente,

39
00:01:48,000 --> 00:01:52,000
e quando finisce, Valgrind verrà stampata una sintesi del suo utilizzo di memoria.

40
00:01:52,000 --> 00:01:58,000
Se tutto va bene, sarà simile a questa:

41
00:01:58,000 --> 00:02:01,000
In questo caso,. / Clean_program

42
00:02:01,000 --> 00:02:04,000
è il percorso del programma da eseguire.

43
00:02:04,000 --> 00:02:06,000
E mentre questo non si richiede alcun argomento,

44
00:02:06,000 --> 00:02:09,000
se così fosse mi piacerebbe semplicemente virare fino alla fine del comando, come al solito.

45
00:02:09,000 --> 00:02:12,000
Programma di Clean è solo un po 'sciocco programma che ho creato

46
00:02:12,000 --> 00:02:15,000
che alloca spazio per un blocco di interi sul mucchio,

47
00:02:15,000 --> 00:02:19,000
mettere alcuni valori all'interno di essi, e libera l'intero blocco.

48
00:02:19,000 --> 00:02:23,000
Questo è ciò che si sta girando per, senza errori e senza perdite.

49
00:02:23,000 --> 00:02:27,000
>> Un altro dato importante è il numero totale di byte allocati.

50
00:02:27,000 --> 00:02:32,000
A seconda del programma, se le assegnazioni sono in megabyte o superiore,

51
00:02:32,000 --> 00:02:34,000
probabilmente stai facendo qualcosa di sbagliato.

52
00:02:34,000 --> 00:02:37,000
Stai inutilmente memorizzazione duplicati?

53
00:02:37,000 --> 00:02:40,000
Si sta utilizzando l'heap per l'archiviazione, quando sarebbe meglio usare la pila?

54
00:02:40,000 --> 00:02:43,000
Così, errori di memoria può essere veramente male.

55
00:02:43,000 --> 00:02:46,000
Quelli più evidenti causare incidenti spettacolari,

56
00:02:46,000 --> 00:02:49,000
ma anche in questo caso può essere ancora difficile individuare

57
00:02:49,000 --> 00:02:51,000
che cosa ha portato al crollo.

58
00:02:51,000 --> 00:02:54,000
Più insidioso, un programma con un errore di memoria

59
00:02:54,000 --> 00:02:56,000
può ancora compilarlo

60
00:02:56,000 --> 00:02:58,000
e può ancora sembrano funzionare correttamente

61
00:02:58,000 --> 00:03:01,000
perché sei riuscito a ottenere fortuna la maggior parte del tempo.

62
00:03:01,000 --> 00:03:04,000
Dopo diversi "risultati positivi",

63
00:03:04,000 --> 00:03:07,000
si potrebbe anche pensare che un incidente è un colpo di fortuna del computer,

64
00:03:07,000 --> 00:03:10,000
ma il computer non è mai sbagliato.

65
00:03:10,000 --> 00:03:13,000
>> Esecuzione Valgrind può aiutare a rintracciare la causa di errori di memoria visibili

66
00:03:13,000 --> 00:03:18,000
così come trovare in agguato gli errori non è nemmeno ancora a conoscenza.

67
00:03:18,000 --> 00:03:22,000
Ogni volta che Valgrind rileva un problema, viene stampato le informazioni su ciò che osserva.

68
00:03:22,000 --> 00:03:24,000
Ogni elemento è abbastanza conciso -

69
00:03:24,000 --> 00:03:27,000
la riga di origine dell'istruzione offendere, qual è il problema,

70
00:03:27,000 --> 00:03:30,000
e un po 'di informazioni sulla memoria coinvolto -

71
00:03:30,000 --> 00:03:34,000
ma spesso è abbastanza informazioni per dirigere la vostra attenzione nel posto giusto.

72
00:03:34,000 --> 00:03:37,000
Ecco un esempio di Valgrind programma in esecuzione su un buggy

73
00:03:37,000 --> 00:03:40,000
che fa una lettura valida di memoria heap.

74
00:03:40,000 --> 00:03:49,000
Vediamo presenti errori o avvisi di compilazione.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, il riassunto di errore dice che ci sono due errori -

76
00:03:53,000 --> 00:03:56,000
due letture non valido di dimensione 4 - byte, che è.

77
00:03:56,000 --> 00:04:01,000
Sia cattiva legge verificato nella funzione principale di invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
la prima linea 16 e la seconda linea 19.

79
00:04:04,000 --> 00:04:06,000
Diamo un'occhiata al codice.

80
00:04:06,000 --> 00:04:11,000
Sembra che la prima chiamata a printf tenta di leggere un int oltre la fine del nostro blocco di memoria.

81
00:04:11,000 --> 00:04:13,000
Se guardiamo indietro all'uscita Valgrind,

82
00:04:13,000 --> 00:04:16,000
vediamo che Valgrind ci ha detto esattamente questo.

83
00:04:16,000 --> 00:04:19,000
L'indirizzo che stiamo cercando di leggere inizia 0 byte

84
00:04:19,000 --> 00:04:22,000
oltre la fine del blocco di misura 16 byte -

85
00:04:22,000 --> 00:04:25,000
quattro a 32 bit interi che noi assegnati.

86
00:04:25,000 --> 00:04:29,000
Vale a dire, l'indirizzo stavamo cercando di leggere inizia proprio alla fine del nostro blocco,

87
00:04:29,000 --> 00:04:32,000
proprio come si vede nella nostra chiamata printf male.

88
00:04:32,000 --> 00:04:36,000
Ora, non valida letture potrebbe non sembrare così grande di un affare,

89
00:04:36,000 --> 00:04:39,000
ma se si sta utilizzando i dati per controllare il flusso del programma -

90
00:04:39,000 --> 00:04:42,000
per esempio, come parte di un'istruzione if o loop -

91
00:04:42,000 --> 00:04:45,000
allora le cose possono andare male in silenzio.

92
00:04:45,000 --> 00:04:47,000
Guarda come posso eseguire il programma invalid_read

93
00:04:47,000 --> 00:04:50,000
e nulla di straordinario accade.

94
00:04:50,000 --> 00:04:52,000
Spaventoso, eh?

95
00:04:52,000 --> 00:04:56,000
>> Ora, diamo un'occhiata a un po 'di più tipi di errori che si possono verificare nel codice,

96
00:04:56,000 --> 00:04:59,000
e vedremo come Valgrind li rileva.

97
00:04:59,000 --> 00:05:01,000
Abbiamo appena visto un esempio di un invalid_read,

98
00:05:01,000 --> 00:05:04,000
così ora diamo un'occhiata un invalid_write.

99
00:05:04,000 --> 00:05:09,000
Anche in questo caso, non ci sono errori o avvisi di compilazione.

100
00:05:09,000 --> 00:05:12,000
Ok, Valgrind dice che ci sono due errori in questo programma -

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

102
00:05:15,000 --> 00:05:18,000
Diamo un'occhiata a questo codice.

103
00:05:18,000 --> 00:05:21,000
Sembra che abbiamo un esempio del classico strlen più un bug.

104
00:05:21,000 --> 00:05:24,000
Il codice non malloc un byte extra di spazio

105
00:05:24,000 --> 00:05:26,000
per il carattere / 0,

106
00:05:26,000 --> 00:05:30,000
così quando str copia è andato a scrivere a ssubstrlen "CS50 rocks!"

107
00:05:30,000 --> 00:05:33,000
ha scritto 1 byte oltre la fine del nostro blocco.

108
00:05:33,000 --> 00:05:36,000
Il invalid_read arriva quando facciamo la nostra chiamata alla printf.

109
00:05:36,000 --> 00:05:40,000
Printf finisce la lettura di memoria non valida quando si legge il / 0 caratteri

110
00:05:40,000 --> 00:05:43,000
come appare alla fine di questa stringa E è la stampa.

111
00:05:43,000 --> 00:05:45,000
Ma niente di tutto questo sfuggito Valgrind.

112
00:05:45,000 --> 00:05:48,000
Vediamo che lo prese il invalid_write come parte della copia str

113
00:05:48,000 --> 00:05:51,000
sulla linea 11 del principale, e il invalid_read è parte di printf.

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

115
00:05:54,000 --> 00:05:57,000
Ancora una volta, questo potrebbe non sembrare un grande affare.

116
00:05:57,000 --> 00:06:00,000
Siamo in grado di eseguire questo programma più e più volte al di fuori di Valgrind

117
00:06:00,000 --> 00:06:03,000
e non vedere alcun sintomo di errore.

118
00:06:03,000 --> 00:06:06,000
>> Tuttavia, diamo un'occhiata a una leggera variazione di questo per vedere

119
00:06:06,000 --> 00:06:09,000
come le cose possono ottenere davvero male.

120
00:06:09,000 --> 00:06:14,000
Quindi, ha concesso, stiamo abusando le cose più che un po 'in questo codice.

121
00:06:14,000 --> 00:06:17,000
Stiamo solo allocare spazio sul mucchio per due stringhe

122
00:06:17,000 --> 00:06:19,000
la lunghezza del CS50 rocce,

123
00:06:19,000 --> 00:06:22,000
questa volta, ricordando il / 0 caratteri.

124
00:06:22,000 --> 00:06:25,000
Ma poi ci buttiamo in un super-lunga stringa nel blocco di memoria

125
00:06:25,000 --> 00:06:27,000
che S sta puntando.

126
00:06:27,000 --> 00:06:30,000
Quali saranno gli effetti che hanno sul blocco di memoria che punta a T?

127
00:06:30,000 --> 00:06:34,000
Beh, se i punti di T alla memoria questo è solo adiacente a S,

128
00:06:34,000 --> 00:06:37,000
venuta solo dopo,

129
00:06:37,000 --> 00:06:39,000
allora potremmo aver scritto su una parte di T.

130
00:06:39,000 --> 00:06:41,000
Corriamo questo codice.

131
00:06:41,000 --> 00:06:43,000
Guardate quello che è successo.

132
00:06:43,000 --> 00:06:47,000
Le stringhe che abbiamo memorizzato nei nostri blocchi di heap entrambi sembravano essere stampati in modo corretto.

133
00:06:47,000 --> 00:06:49,000
Nulla sembra male a tutti.

134
00:06:49,000 --> 00:06:52,000
Comunque, torniamo nel nostro codice e

135
00:06:52,000 --> 00:06:55,000
commentare la riga in cui copiamo CS50 rocce

136
00:06:55,000 --> 00:06:59,000
nel secondo blocco di memoria, puntata da t.

137
00:06:59,000 --> 00:07:02,000
Ora, quando si esegue questo codice dovremmo

138
00:07:02,000 --> 00:07:06,000
solo vedere il contenuto del primo blocco di memoria stampare.

139
00:07:06,000 --> 00:07:09,000
Ehi, anche se non abbiamo str copia

140
00:07:09,000 --> 00:07:12,000
tutti i caratteri nel blocco heap secondo, quello puntato da T,

141
00:07:12,000 --> 00:07:15,000
si ottiene una stampa.

142
00:07:15,000 --> 00:07:18,000
Infatti, la stringa che abbiamo farcito nel nostro primo blocco

143
00:07:18,000 --> 00:07:21,000
sorpassato il primo blocco e nel secondo blocco,

144
00:07:21,000 --> 00:07:23,000
facendo sembrare tutto normale.

145
00:07:23,000 --> 00:07:26,000
Valgrind, però, ci racconta la vera storia.

146
00:07:26,000 --> 00:07:28,000
Ecco fatto.

147
00:07:28,000 --> 00:07:32,000
Tutti quelli non valido di lettura e scrittura.

148
00:07:32,000 --> 00:07:36,000
>> Vediamo un esempio di un altro tipo di errore.

149
00:07:36,000 --> 00:07:39,000
Qui facciamo qualcosa di spiacevole.

150
00:07:39,000 --> 00:07:41,000
Prendiamo lo spazio per un int sul mucchio,

151
00:07:41,000 --> 00:07:45,000
e inizializzare un puntatore a int - p - per puntare a quello spazio.

152
00:07:45,000 --> 00:07:48,000
Tuttavia, mentre il nostro puntatore è inizializzato,

153
00:07:48,000 --> 00:07:52,000
i dati che esso punta a poco tutto ciò che è spazzatura è in quella parte del mucchio.

154
00:07:52,000 --> 00:07:55,000
Così, quando si caricano i dati in int i,

155
00:07:55,000 --> 00:07:57,000
abbiamo tecnicamente i inizializzazione,

156
00:07:57,000 --> 00:08:00,000
ma lo facciamo con i dati spazzatura.

157
00:08:00,000 --> 00:08:03,000
La chiamata di affermare, che è una macro di debug a portata di mano

158
00:08:03,000 --> 00:08:06,000
definito nel nome appropriato affermare biblioteca,

159
00:08:06,000 --> 00:08:09,000
verrà interrotto il programma se la sua condizione di test ha esito negativo.

160
00:08:09,000 --> 00:08:11,000
Cioè, se i non è 0.

161
00:08:11,000 --> 00:08:14,000
A seconda di cosa è stato nello spazio heap, puntato da p,

162
00:08:14,000 --> 00:08:18,000
questo programma potrebbe funzionare a volte e non in altri momenti.

163
00:08:18,000 --> 00:08:20,000
Se funziona, siamo solo fortunati.

164
00:08:20,000 --> 00:08:24,000
Il compilatore non prenderà questo errore, ma Valgrind volontà sicuro.

165
00:08:24,000 --> 00:08:28,000
Ci si vede l'errore derivante dal nostro uso di tali dati spazzatura.

166
00:08:28,000 --> 00:08:32,000
>> Quando si alloca memoria heap ma non rilasciare o liberarlo,

167
00:08:32,000 --> 00:08:34,000
che è chiamata una perdita.

168
00:08:34,000 --> 00:08:37,000
Per un piccolo, breve programma che gira ed esce immediatamente,

169
00:08:37,000 --> 00:08:39,000
le perdite sono abbastanza innocui,

170
00:08:39,000 --> 00:08:42,000
ma per un progetto di grandi dimensioni e / o longevità,

171
00:08:42,000 --> 00:08:46,000
anche una piccola perdita può aggravare in qualcosa di importante.

172
00:08:46,000 --> 00:08:49,000
Per CS50, ci aspettiamo di

173
00:08:49,000 --> 00:08:51,000
prendersi cura di liberare tutta la memoria heap di allocare,

174
00:08:51,000 --> 00:08:54,000
dal momento che vogliamo voi per costruire la capacità di gestire correttamente il processo manuale

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

176
00:08:56,000 --> 00:08:59,000
Per fare ciò, il programma dovrebbe avere una esatta

177
00:08:59,000 --> 00:09:03,000
uno-a-uno corrispondenza tra malloc e chiamate gratuite.

178
00:09:03,000 --> 00:09:06,000
Fortunatamente, Valgrind può aiutare con perdite di memoria troppo.

179
00:09:06,000 --> 00:09:09,000
Ecco un programma che perde chiamato perdite.C che alloca

180
00:09:09,000 --> 00:09:13,000
spazio sul mucchio, scrive ad esso, ma non lo libera.

181
00:09:13,000 --> 00:09:16,000
Abbiamo compilarlo con Make ed eseguirlo sotto Valgrind,

182
00:09:16,000 --> 00:09:18,000
e vediamo che, mentre non abbiamo errori di memoria,

183
00:09:18,000 --> 00:09:20,000
noi abbiamo uno perdita.

184
00:09:20,000 --> 00:09:23,000
Ci sono 16 byte definitivamente perduti,

185
00:09:23,000 --> 00:09:27,000
il che significa che il puntatore che la memoria non era in campo quando il programma è terminato.

186
00:09:27,000 --> 00:09:30,000
Ora, Valgrind non ci dà un sacco di informazioni sulla perdita,

187
00:09:30,000 --> 00:09:35,000
ma se seguiamo questa piccola nota che dà verso il fondo della sua relazione

188
00:09:35,000 --> 00:09:38,000
eseguire di nuovo con - perdita-check = full

189
00:09:38,000 --> 00:09:41,000
per vedere i dettagli di perdita di memoria,

190
00:09:41,000 --> 00:09:44,000
avremo ulteriori informazioni.

191
00:09:44,000 --> 00:09:46,000
Ora, nel riassunto mucchio,

192
00:09:46,000 --> 00:09:50,000
Valgrind ci dice dove la memoria che è stato perso è stata inizialmente attribuita.

193
00:09:50,000 --> 00:09:52,000
Così come sappiamo dal guardare nel codice sorgente,

194
00:09:52,000 --> 00:09:55,000
Valgrind ci informa che si perdeva la memoria

195
00:09:55,000 --> 00:09:58,000
assegnato con una chiamata a malloc sulla linea 8 del perdite.C

196
00:09:58,000 --> 00:10:00,000
nella funzione principale.

197
00:10:00,000 --> 00:10:02,000
Piuttosto carino.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind classifica perdite usando questi termini:

199
00:10:04,000 --> 00:10:07,000
Sicuramente ha perso - questa è heap memoria allocata

200
00:10:07,000 --> 00:10:10,000
in cui il programma non ha più un puntatore.

201
00:10:10,000 --> 00:10:14,000
Valgrind sa che una volta avuto il puntatore, ma da allora hanno perso le tracce di esso.

202
00:10:14,000 --> 00:10:17,000
Questa memoria è sicuramente trapelato.

203
00:10:17,000 --> 00:10:20,000
Indirettamente perso - questa è heap memoria allocata

204
00:10:20,000 --> 00:10:24,000
a cui solo i puntatori alle anche vengono persi.

205
00:10:24,000 --> 00:10:27,000
Ad esempio, se hai perso il puntatore al primo nodo di una lista concatenata,

206
00:10:27,000 --> 00:10:30,000
quindi il primo nodo stessa sarebbe definitivamente perduto,

207
00:10:30,000 --> 00:10:34,000
mentre tutti i nodi successivi sarebbe indirettamente persa.

208
00:10:34,000 --> 00:10:37,000
Forse ha perso - questa è heap memoria allocata

209
00:10:37,000 --> 00:10:41,000
a cui Valgrind non può essere sicuri che vi sia un puntatore o meno.

210
00:10:41,000 --> 00:10:44,000
Ancora raggiungibile è heap memoria allocata

211
00:10:44,000 --> 00:10:47,000
in cui il programma ha ancora un puntatore in uscita,

212
00:10:47,000 --> 00:10:50,000
il che significa in genere che un punto variabile globale ad esso.

213
00:10:50,000 --> 00:10:53,000
Per verificare la presenza di queste fughe di notizie, avrete anche la possibilità di includere

214
00:10:53,000 --> 00:10:55,000
- Ancora raggiungibile = yes

215
00:10:55,000 --> 00:10:58,000
nella tua invocazione di Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Questi casi possono richiedere diverse strategie diverse per la pulizia in su,

217
00:11:01,000 --> 00:11:05,000
ma le perdite devono essere eliminate.

218
00:11:05,000 --> 00:11:08,000
Purtroppo, fissando le perdite possono essere difficile da fare,

219
00:11:08,000 --> 00:11:11,000
poiché quelle non corrette per liberare far saltare in aria il vostro programma.

220
00:11:11,000 --> 00:11:14,000
Per esempio, se guardiamo alla invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
vediamo un esempio di deallocazione brutto ricordo.

222
00:11:18,000 --> 00:11:21,000
Quale dovrebbe essere una singola chiamata per liberare l'intero blocco

223
00:11:21,000 --> 00:11:24,000
di memoria puntato da int_block,

224
00:11:24,000 --> 00:11:27,000
è invece diventato un tentativo di liberare ogni int imprese sezione

225
00:11:27,000 --> 00:11:29,000
della memoria individuale.

226
00:11:29,000 --> 00:11:32,000
In questo modo non catastrofico.

227
00:11:32,000 --> 00:11:34,000
Boom! Nei un errore.

228
00:11:34,000 --> 00:11:36,000
Questo non è sicuramente buona.

229
00:11:36,000 --> 00:11:39,000
Se sei bloccato con questo tipo di errore, però, e non si sa dove guardare,

230
00:11:39,000 --> 00:11:41,000
ripiegare sul tuo nuovo migliore amico.

231
00:11:41,000 --> 00:11:44,000
Avete indovinato - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, come sempre, sa esattamente cosa succede.

233
00:11:47,000 --> 00:11:50,000
I conteggi alloc e libero non coincidono.

234
00:11:50,000 --> 00:11:52,000
Abbiamo ottenuto 1 alloc e 4 libera.

235
00:11:52,000 --> 00:11:55,000
E Valgrind ci dice anche dove la prima chiamata cattivo libero -

236
00:11:55,000 --> 00:11:58,000
quella che ha attivato l'ingrandimento - proviene -

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

238
00:12:00,000 --> 00:12:03,000
Come potete vedere, le chiamate cattivi per liberare sono davvero male,

239
00:12:03,000 --> 00:12:05,000
quindi si consiglia di lasciare il vostro programma di perdita di

240
00:12:05,000 --> 00:12:08,000
mentre si sta lavorando per ottenere la corretta funzionalità.

241
00:12:08,000 --> 00:12:12,000
Iniziare la ricerca di perdite solo dopo che il programma funziona correttamente,

242
00:12:12,000 --> 00:12:14,000
senza altri errori.

243
00:12:14,000 --> 00:12:16,000
>> E questo è tutto quello che abbiamo per questo video.

244
00:12:16,000 --> 00:12:18,000
Ora, che cosa stai aspettando?

245
00:12:18,000 --> 00:12:21,000
Vai eseguire Valgrind sui programmi al momento.

246
00:12:21,000 --> 00:12:25,000
Il mio nome è Nate Hardison. Questo è CS50. [CS50.TV]