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
Dies ist CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
Einige der schwierigsten Fehler in C-Programmen

5
00:00:10,000 --> 00:00:13,000
kommen aus dem Missmanagement der Erinnerung.

6
00:00:13,000 --> 00:00:15,000
Es gibt eine große Anzahl von Möglichkeiten, Dinge zu vermasseln,

7
00:00:15,000 --> 00:00:17,000
einschließlich Zuweisung die falsche Menge an Speicher,

8
00:00:17,000 --> 00:00:20,000
vergessen, Variablen zu initialisieren,

9
00:00:20,000 --> 00:00:23,000
Schreiben vor oder nach dem Ende eines Puffers,

10
00:00:23,000 --> 00:00:25,000
und Befreiung zu halten Speicher mehrmals.

11
00:00:25,000 --> 00:00:28,000
Die Symptome reichen von unerwarteten Abstürzen

12
00:00:28,000 --> 00:00:30,000
auf mysteriöse Weise überschrieben Werte,

13
00:00:30,000 --> 00:00:34,000
oft an Orten und zu Zeiten weit von der ursprünglichen Fehler entfernt.

14
00:00:34,000 --> 00:00:37,000
Auf den Spuren der beobachteten Problem wieder auf die zugrunde liegende Ursache

15
00:00:37,000 --> 00:00:39,000
kann eine Herausforderung sein,

16
00:00:39,000 --> 00:00:42,000
aber zum Glück gibt es eine hilfreiche Programm namens Valgrind

17
00:00:42,000 --> 00:00:44,000
das kann viel tun, um zu helfen.

18
00:00:44,000 --> 00:00:47,000
>> Sie führen ein Programm unter Valgrind zu ermöglichen

19
00:00:47,000 --> 00:00:50,000
umfangreiche Überprüfung des Heap-Speichers Zuweisungen und Zugänge.

20
00:00:50,000 --> 00:00:53,000
Wenn Valgrind ein Problem erkennt, gibt es Ihnen sofort,

21
00:00:53,000 --> 00:00:56,000
direkte Informationen, die Ihnen erlaubt,

22
00:00:56,000 --> 00:00:58,000
leichter zu finden und das Problem beheben.

23
00:00:58,000 --> 00:01:01,000
Valgrind auch Berichte über weniger tödlich Probleme mit dem Arbeitsspeicher,

24
00:01:01,000 --> 00:01:04,000
wie Speicherlecks, Zuteilung Heap-Speicher,

25
00:01:04,000 --> 00:01:07,000
und vergessen, sie zu befreien.

26
00:01:07,000 --> 00:01:10,000
Wie unsere Compiler, Clang in unserem Debugger GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind ist freie Software, und es wird auf dem Gerät installiert.

28
00:01:14,000 --> 00:01:16,000
Valgrind läuft auf Ihrem Binärformat,

29
00:01:16,000 --> 00:01:20,000
nicht Ihre. c oder. h Quellcodedateien,

30
00:01:20,000 --> 00:01:23,000
so sicher sein, Sie haben eine up-to-date Kopie Ihrer Programm kompiliert

31
00:01:23,000 --> 00:01:25,000
Verwendung Clang Oder.

32
00:01:25,000 --> 00:01:28,000
Dann kann Ihr Programm unter Valgrind werden

33
00:01:28,000 --> 00:01:32,000
so einfach wie nur voranstellen das Standard-Programm-Befehl mit dem Wort Valgrind,

34
00:01:32,000 --> 00:01:35,000
die startet Valgrind und läuft das Programm im Inneren.

35
00:01:35,000 --> 00:01:38,000
Beim Starten tut Valgrind einige komplexe

36
00:01:38,000 --> 00:01:41,000
Überdrehen um die ausführbare Datei für die Speicher-Überprüfungen konfigurieren,

37
00:01:41,000 --> 00:01:44,000
so kann es noch ein bisschen aufstehen und laufen.

38
00:01:44,000 --> 00:01:48,000
Das Programm wird dann normal ausgeführt, sei es viel langsamer,

39
00:01:48,000 --> 00:01:52,000
und wenn es fertig ist, wird Valgrind drucken eine Zusammenfassung seiner Speichernutzung.

40
00:01:52,000 --> 00:01:58,000
Wenn alles gut geht, wird es in etwa so aussehen:

41
00:01:58,000 --> 00:02:01,000
In diesem Fall. / Clean_program

42
00:02:01,000 --> 00:02:04,000
ist der Pfad zu dem Programm, das ich ausführen möchten.

43
00:02:04,000 --> 00:02:06,000
Und während dieses hat keine Argumente,

44
00:02:06,000 --> 00:02:09,000
wenn es das täte würde ich nur tack sie an das Ende des Befehls wie gewohnt.

45
00:02:09,000 --> 00:02:12,000
Saubere Programm ist nur ein dummes kleines Programm habe ich

46
00:02:12,000 --> 00:02:15,000
das Speicherplatz für einen Block von ints auf dem Heap,

47
00:02:15,000 --> 00:02:19,000
setzen einige Werte innerhalb von ihnen, und befreit den ganzen Block.

48
00:02:19,000 --> 00:02:23,000
Dies ist, was Sie suchen, ohne Fehler und ohne Lecks schießen.

49
00:02:23,000 --> 00:02:27,000
>> Eine weitere wichtige Metrik ist die Gesamtanzahl von zugewiesenen Bytes.

50
00:02:27,000 --> 00:02:32,000
Je nach Programm, wenn Ihr Zuweisungen in den Megabyte oder höher sind,

51
00:02:32,000 --> 00:02:34,000
sind Sie wahrscheinlich etwas falsch machen.

52
00:02:34,000 --> 00:02:37,000
Sind Sie nicht unnötig speichert Duplikate?

53
00:02:37,000 --> 00:02:40,000
Sind Sie mit dem Heap für Lagerung, wenn es besser wäre, den Stapel zu verwenden?

54
00:02:40,000 --> 00:02:43,000
So kann der Speicher Fehler wirklich böse.

55
00:02:43,000 --> 00:02:46,000
Je mehr offene Hosen zu spektakulären Stürzen,

56
00:02:46,000 --> 00:02:49,000
aber selbst dann kann es immer noch schwer zu lokalisieren

57
00:02:49,000 --> 00:02:51,000
was genau führte zum Absturz.

58
00:02:51,000 --> 00:02:54,000
Mehr schleichend, ein Programm mit einer Speicher-Fehler

59
00:02:54,000 --> 00:02:56,000
kann noch sauber kompilieren

60
00:02:56,000 --> 00:02:58,000
und scheinen immer noch korrekt funktionieren

61
00:02:58,000 --> 00:03:01,000
weil du es geschafft, mit etwas Glück die meisten der Zeit.

62
00:03:01,000 --> 00:03:04,000
Nach mehreren "erfolgreichen Ergebnissen"

63
00:03:04,000 --> 00:03:07,000
Sie können nur denken, dass ein Crash ein Glücksfall des Computers ist,

64
00:03:07,000 --> 00:03:10,000
aber der Computer ist nie verkehrt.

65
00:03:10,000 --> 00:03:13,000
>> Laufen Valgrind können Ihnen helfen, die Spur der Ursache der sichtbare Speicher Fehler

66
00:03:13,000 --> 00:03:18,000
sowie zu finden lauern Fehler, die Sie noch gar nicht kennen.

67
00:03:18,000 --> 00:03:22,000
Jedes Mal, wenn Valgrind ein Problem feststellt, druckt es Informationen darüber, was es beobachtet.

68
00:03:22,000 --> 00:03:24,000
Jedes Element ist ziemlich knappe -

69
00:03:24,000 --> 00:03:27,000
die Source-Leitung des betreffenden Anweisung, was das Problem ist,

70
00:03:27,000 --> 00:03:30,000
und ein wenig Informationen über den Speicher beteiligt -

71
00:03:30,000 --> 00:03:34,000
aber oft ist es genug Informationen, um Ihre Aufmerksamkeit auf die richtige Stelle weiter.

72
00:03:34,000 --> 00:03:37,000
Hier ist ein Beispiel für Valgrind läuft auf einem Buggy-Programm

73
00:03:37,000 --> 00:03:40,000
das tut eine ungültige Lesen von Heap-Speicher.

74
00:03:40,000 --> 00:03:49,000
Wir sehen keine Fehler oder Warnungen in der Zusammenstellung.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, sagt der Fehler Zusammenfassung, dass es zwei Fehler -

76
00:03:53,000 --> 00:03:56,000
zwei ungültige Lesevorgänge der Größe 4 - Byte, das ist.

77
00:03:56,000 --> 00:04:01,000
Beide schlechten liest traten in der Hauptfunktion invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
die erste auf der Leitung 16 und der zweiten auf der Leitung 19.

79
00:04:04,000 --> 00:04:06,000
Lassen Sie uns auf den Code schauen.

80
00:04:06,000 --> 00:04:11,000
Sieht aus wie der erste Aufruf von printf versucht, ein int über das Ende unserer Speicherblock gelesen.

81
00:04:11,000 --> 00:04:13,000
Wenn wir blicken zurück auf Valgrind-Ausgang,

82
00:04:13,000 --> 00:04:16,000
sehen wir, dass Valgrind uns gesagt, genau dies.

83
00:04:16,000 --> 00:04:19,000
Die Adresse, die wir versuchen zu lesen sind beginnt 0 Byte

84
00:04:19,000 --> 00:04:22,000
über das Ende des Blocks der Größe 16 Bytes -

85
00:04:22,000 --> 00:04:25,000
vier 32-Bit-Ganzzahlen dass wir zugeordnet.

86
00:04:25,000 --> 00:04:29,000
Das ist, beginnt die Adresse, die wir versuchen zu lesen waren ganz am Ende unseres Blocks,

87
00:04:29,000 --> 00:04:32,000
wie wir sehen in unserer schlechten printf.

88
00:04:32,000 --> 00:04:36,000
Nun könnte ungültige Lesevorgänge nicht wie die große Sache scheinen,

89
00:04:36,000 --> 00:04:39,000
aber wenn Sie mit, dass die Daten, um den Fluss des Programms zu kontrollieren -

90
00:04:39,000 --> 00:04:42,000
zum Beispiel als Teil einer if-Anweisung oder eine Schleife -

91
00:04:42,000 --> 00:04:45,000
dann kann es lautlos gehen schlecht.

92
00:04:45,000 --> 00:04:47,000
Beobachten Sie, wie kann ich die invalid_read Programm ausführen

93
00:04:47,000 --> 00:04:50,000
und nichts aus dem Üblichen heraus geschieht.

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

95
00:04:52,000 --> 00:04:56,000
>> Lassen Sie uns nun auf einige weitere Arten von Fehlern, die Sie in Ihrem Code auftreten aussehen könnte,

96
00:04:56,000 --> 00:04:59,000
und wir werden sehen, wie Valgrind sie erkennt.

97
00:04:59,000 --> 00:05:01,000
Wir sahen nur ein Beispiel für eine invalid_read,

98
00:05:01,000 --> 00:05:04,000
so jetzt lasst uns bitte eine invalid_write.

99
00:05:04,000 --> 00:05:09,000
Wieder keine Fehler oder Warnungen in der Zusammenstellung.

100
00:05:09,000 --> 00:05:12,000
Ausreichend, sagt Valgrind dass es zwei Fehler in diesem Programm -

101
00:05:12,000 --> 00:05:15,000
und invalid_write und ein invalid_read.

102
00:05:15,000 --> 00:05:18,000
Sehen wir uns diesen Code.

103
00:05:18,000 --> 00:05:21,000
Sieht aus wie wir eine Instanz des klassischen strlen plus ein bug habe.

104
00:05:21,000 --> 00:05:24,000
Der Code nicht malloc ein zusätzliches Byte Platz

105
00:05:24,000 --> 00:05:26,000
für die / 0 Charakter,

106
00:05:26,000 --> 00:05:30,000
so, wenn str Kopie an es ssubstrlen schreiben ging "CS50 rocks!"

107
00:05:30,000 --> 00:05:33,000
schrieb er 1 Byte über das Ende unseres Blocks.

108
00:05:33,000 --> 00:05:36,000
Die invalid_read kommt, wenn wir unseren Aufruf printf machen.

109
00:05:36,000 --> 00:05:40,000
Printf endet Lesen ungültigen Speicherzugriff, wenn es die / 0 Zeichen liest

110
00:05:40,000 --> 00:05:43,000
wie es am Ende dieser E-Saite sieht es Druck.

111
00:05:43,000 --> 00:05:45,000
Aber nichts davon entgangen Valgrind.

112
00:05:45,000 --> 00:05:48,000
Wir sehen, dass es die invalid_write gefangen, als Teil des str Kopie

113
00:05:48,000 --> 00:05:51,000
on line 11 von Haupt-, und die invalid_read ist Teil printf.

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

115
00:05:54,000 --> 00:05:57,000
Wiederum kann dies nicht wie eine große Sache zu sein scheinen.

116
00:05:57,000 --> 00:06:00,000
Wir können dieses Programm über und über laufen außerhalb der Valgrind

117
00:06:00,000 --> 00:06:03,000
und sehen keine Fehlersymptome.

118
00:06:03,000 --> 00:06:06,000
>> Aber lassen Sie in einem leichten Variation aussehen zu sehen

119
00:06:06,000 --> 00:06:09,000
wie die Dinge können sich wirklich schlecht.

120
00:06:09,000 --> 00:06:14,000
So gewährte, sind wir missbrauchen Dinge mehr als nur ein bisschen in diesem Code.

121
00:06:14,000 --> 00:06:17,000
Wir sind nur Zuweisung von Speicherplatz auf dem Heap für zwei Strings

122
00:06:17,000 --> 00:06:19,000
die Länge des CS50 Felsen,

123
00:06:19,000 --> 00:06:22,000
dieses Mal die Erinnerung an die / 0 Charakter.

124
00:06:22,000 --> 00:06:25,000
Aber dann haben wir in einem super-langen Schnur zu werfen in den Speicherblock

125
00:06:25,000 --> 00:06:27,000
das S verweist.

126
00:06:27,000 --> 00:06:30,000
Welche Auswirkungen hat das auf den Speicherblock, dass T Punkte?

127
00:06:30,000 --> 00:06:34,000
Nun, wenn T Punkten auf Speicher, direkt neben S ist,

128
00:06:34,000 --> 00:06:37,000
kommen kurz danach,

129
00:06:37,000 --> 00:06:39,000
dann könnten wir über einen Teil T. geschrieben haben

130
00:06:39,000 --> 00:06:41,000
Lassen Sie diesen Code ausführen.

131
00:06:41,000 --> 00:06:43,000
Schauen Sie, was passiert ist.

132
00:06:43,000 --> 00:06:47,000
Die Saiten wir in unserem Heapblöcke beiden gespeicherten schien korrekt gedruckt wurden.

133
00:06:47,000 --> 00:06:49,000
Nichts scheint überhaupt falsch.

134
00:06:49,000 --> 00:06:52,000
Allerdings gehen wir zurück in unser Code und

135
00:06:52,000 --> 00:06:55,000
kommentieren Sie die Zeile, wo wir CS50 Felsen kopieren

136
00:06:55,000 --> 00:06:59,000
in den zweiten Speicherblock, auf den durch t.

137
00:06:59,000 --> 00:07:02,000
Nun, wenn wir diesen Code ausführen sollten wir

138
00:07:02,000 --> 00:07:06,000
sehen nur den Inhalt des ersten Speicherblock auszudrucken.

139
00:07:06,000 --> 00:07:09,000
Whoa, obwohl wir nicht str Kopie

140
00:07:09,000 --> 00:07:12,000
alle Zeichen in die zweite Heap-Block wies die ein durch T,

141
00:07:12,000 --> 00:07:15,000
erhalten wir einen Ausdruck.

142
00:07:15,000 --> 00:07:18,000
In der Tat, die Zeichenfolge wir gefüllt in unserer ersten Block

143
00:07:18,000 --> 00:07:21,000
überstieg den ersten Block und in den zweiten Block,

144
00:07:21,000 --> 00:07:23,000
macht alles scheint normal.

145
00:07:23,000 --> 00:07:26,000
Valgrind, obwohl, erzählt uns die wahre Geschichte.

146
00:07:26,000 --> 00:07:28,000
Dort gehen wir.

147
00:07:28,000 --> 00:07:32,000
Alle diejenigen, ungültige liest und schreibt.

148
00:07:32,000 --> 00:07:36,000
>> Lassen Sie uns auf ein Beispiel für eine andere Art von Fehler zu suchen.

149
00:07:36,000 --> 00:07:39,000
Hier haben wir etwas tun, eher unglücklich.

150
00:07:39,000 --> 00:07:41,000
Wir schnappen Platz für ein int auf dem Heap,

151
00:07:41,000 --> 00:07:45,000
und initialisieren wir einen int-Zeiger - p - zu diesem Raum zeigen.

152
00:07:45,000 --> 00:07:48,000
Doch während unsere Zeiger initialisiert wird,

153
00:07:48,000 --> 00:07:52,000
die Daten, dass es auf den Hinweis soeben was immer Junk ist in dem Teil des Haufens.

154
00:07:52,000 --> 00:07:55,000
Also, wenn wir die Daten laden in int i,

155
00:07:55,000 --> 00:07:57,000
wir technisch initialisieren i,

156
00:07:57,000 --> 00:08:00,000
aber wir tun dies mit Datenmüll.

157
00:08:00,000 --> 00:08:03,000
Der Aufruf zu behaupten, das ist ein handliches Debugging Makro

158
00:08:03,000 --> 00:08:06,000
definiert in der treffend benannte behaupten Bibliothek,

159
00:08:06,000 --> 00:08:09,000
bricht das Programm, ob seine Test Bedingung nicht erfüllt.

160
00:08:09,000 --> 00:08:11,000
Das heißt, wenn ich nicht gleich 0 ist.

161
00:08:11,000 --> 00:08:14,000
Je nachdem, was war in der Heap-Speicher, auf den durch p,

162
00:08:14,000 --> 00:08:18,000
Dieses Programm könnte manchmal arbeiten und nicht zu anderen Zeiten.

163
00:08:18,000 --> 00:08:20,000
Wenn es funktioniert, sind wir nur immer Glück.

164
00:08:20,000 --> 00:08:24,000
Der Compiler wird nicht fangen diesen Fehler, aber Valgrind sicher Willen.

165
00:08:24,000 --> 00:08:28,000
Dort sehen wir den Fehler, die sich aus unseren Verwendung dieser Datenmüll.

166
00:08:28,000 --> 00:08:32,000
>> Wenn Sie Heap-Speicher zugewiesen, aber nicht freigeben es oder befreien sie,

167
00:08:32,000 --> 00:08:34,000
Das nennt man ein Leck.

168
00:08:34,000 --> 00:08:37,000
Für eine kleine, kurzlebige Programm, und läuft sofort beendet,

169
00:08:37,000 --> 00:08:39,000
Undichtigkeiten sind ziemlich harmlos,

170
00:08:39,000 --> 00:08:42,000
aber für ein Projekt der größeren Größe und / oder Langlebigkeit,

171
00:08:42,000 --> 00:08:46,000
sogar ein kleines Leck kann in etwas größeren verschlimmern.

172
00:08:46,000 --> 00:08:49,000
Für CS50, wir erwarten, dass Sie

173
00:08:49,000 --> 00:08:51,000
kümmern zu befreien alle Heap-Speicher, die Sie zuweisen,

174
00:08:51,000 --> 00:08:54,000
da wir möchten, dass Sie die Fähigkeiten aufbauen, um ordnungsgemäß zu behandeln den manuellen Prozess

175
00:08:54,000 --> 00:08:56,000
Bedarf von C.

176
00:08:56,000 --> 00:08:59,000
Um dies zu tun, sollte Ihr Programm eine genaue

177
00:08:59,000 --> 00:09:03,000
Eins-zu-eins-Entsprechung zwischen malloc und free Anrufe.

178
00:09:03,000 --> 00:09:06,000
Glücklicherweise kann Valgrind Sie mit Speicherlecks zu helfen.

179
00:09:06,000 --> 00:09:09,000
Hier ist eine undichte Programm namens leak.c, dass zuweist

180
00:09:09,000 --> 00:09:13,000
Speicherraum in dem Haufen, schreibt in ihn, aber nicht befreit werden.

181
00:09:13,000 --> 00:09:16,000
Wir erarbeiten mit Marke und führen Sie es unter Valgrind,

182
00:09:16,000 --> 00:09:18,000
und wir sehen, dass, während wir keine Memory-Fehler haben,

183
00:09:18,000 --> 00:09:20,000
wir haben ein Leck.

184
00:09:20,000 --> 00:09:23,000
Es gibt 16 Bytes endgültig verloren,

185
00:09:23,000 --> 00:09:27,000
bedeutet, dass der Zeiger auf diesen Speicher nicht im Bereich, wenn das Programm beendet wird.

186
00:09:27,000 --> 00:09:30,000
Nun bedeutet Valgrind uns nicht eine Unmenge an Informationen über das Leck,

187
00:09:30,000 --> 00:09:35,000
aber wenn wir diesen kleinen Zettel, dass es sich ergibt nach unten seines Berichts

188
00:09:35,000 --> 00:09:38,000
mit erneut - Leck-Check = full

189
00:09:38,000 --> 00:09:41,000
um die vollen Details durchgesickert Speicher zu sehen,

190
00:09:41,000 --> 00:09:44,000
wir weitere Informationen erhalten.

191
00:09:44,000 --> 00:09:46,000
Jetzt, in der Halde Zusammenfassung

192
00:09:46,000 --> 00:09:50,000
Valgrind sagt uns, wo die Erinnerung, das verloren war ursprünglich zugewiesen wurde.

193
00:09:50,000 --> 00:09:52,000
So wie wir von der Suche im Quellcode wissen,

194
00:09:52,000 --> 00:09:55,000
Valgrind informiert uns, dass wir die Erinnerung durchgesickert

195
00:09:55,000 --> 00:09:58,000
zugeordnet mit einem Aufruf von malloc on line 8 von leak.c

196
00:09:58,000 --> 00:10:00,000
in der Funktion main.

197
00:10:00,000 --> 00:10:02,000
Ziemlich raffiniert.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind kategorisiert Lecks mit diesen Worten:

199
00:10:04,000 --> 00:10:07,000
Endgültig verloren - das ist Heap-Speicher

200
00:10:07,000 --> 00:10:10,000
, auf die das Programm nicht mehr einen Zeiger.

201
00:10:10,000 --> 00:10:14,000
Valgrind weiß, dass Sie hatte einmal die Zeiger, sondern seit Spur von ihm verloren.

202
00:10:14,000 --> 00:10:17,000
Dieser Speicher ist definitiv durchgesickert.

203
00:10:17,000 --> 00:10:20,000
Indirekt verloren - das ist Heap-Speicher

204
00:10:20,000 --> 00:10:24,000
an die die nur Zeiger, um es ebenfalls verloren.

205
00:10:24,000 --> 00:10:27,000
Zum Beispiel, wenn Sie verloren Ihre Zeiger auf den ersten Knoten einer verketteten Liste,

206
00:10:27,000 --> 00:10:30,000
dann der erste Knoten selbst würde definitiv verloren,

207
00:10:30,000 --> 00:10:34,000
während alle weiteren Knoten würde indirekt verloren.

208
00:10:34,000 --> 00:10:37,000
Möglicherweise verloren - das ist Heap-Speicher

209
00:10:37,000 --> 00:10:41,000
, denen Valgrind kann nicht sicher sein, ob es einen Zeiger oder nicht.

210
00:10:41,000 --> 00:10:44,000
Noch erreichbar ist Heap-Speicher

211
00:10:44,000 --> 00:10:47,000
zu denen das Programm noch einen Zeiger an der Ausfahrt,

212
00:10:47,000 --> 00:10:50,000
das bedeutet normalerweise, dass eine globale Variable verweist.

213
00:10:50,000 --> 00:10:53,000
Um diese Lecks zu überprüfen, werden Sie auch die Option beinhalten

214
00:10:53,000 --> 00:10:55,000
- Immer noch erreichbar = yes

215
00:10:55,000 --> 00:10:58,000
in Ihrem Aufruf von Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Diese verschiedenen Fälle könnten unterschiedliche Strategien für die Reinigung sie bis erfordern,

217
00:11:01,000 --> 00:11:05,000
aber Lecks sollten beseitigt werden.

218
00:11:05,000 --> 00:11:08,000
Leider kann Fixierung Lecks schwer zu tun,

219
00:11:08,000 --> 00:11:11,000
da eine falsche Anrufe zu kostenlosen blasen kann Ihr Programm.

220
00:11:11,000 --> 00:11:14,000
Zum Beispiel, wenn wir uns invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
sehen wir ein Beispiel für schlechte Speicherfreigabe.

222
00:11:18,000 --> 00:11:21,000
Was sollte ein einziger Anruf, um den ganzen Block zu befreien

223
00:11:21,000 --> 00:11:24,000
der Speicher, auf den int_block,

224
00:11:24,000 --> 00:11:27,000
Stattdessen hat sich ein Versuch, um jeden int-sized Abschnitt befreien

225
00:11:27,000 --> 00:11:29,000
der Speicher individuell.

226
00:11:29,000 --> 00:11:32,000
Dies wird katastrophal versagen.

227
00:11:32,000 --> 00:11:34,000
Boom! Was für ein Fehler.

228
00:11:34,000 --> 00:11:36,000
Dies ist definitiv nicht gut.

229
00:11:36,000 --> 00:11:39,000
Wenn Sie mit dieser Art von Fehler stecken, aber, und Sie nicht wissen, wo sie suchen müssen,

230
00:11:39,000 --> 00:11:41,000
zurückgreifen zu Ihrem neuen besten Freund.

231
00:11:41,000 --> 00:11:44,000
Sie haben es erraten - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, wie immer, weiß genau, was los ist.

233
00:11:47,000 --> 00:11:50,000
Die alloc und frei zählt nicht mithalten.

234
00:11:50,000 --> 00:11:52,000
Wir haben 1 alloc und 4 befreit.

235
00:11:52,000 --> 00:11:55,000
Und Valgrind sagt uns auch, wo die erste schlechte kostenlosen Anruf -

236
00:11:55,000 --> 00:11:58,000
derjenige, der die blowup ausgelöst - herkommt -

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

238
00:12:00,000 --> 00:12:03,000
Wie Sie sehen, sind schlechte Calls zu befreien wirklich schlecht,

239
00:12:03,000 --> 00:12:05,000
so dass wir empfehlen, dass Sie Ihr Programm Leck

240
00:12:05,000 --> 00:12:08,000
während du auf immer die Funktionalität richtige Arbeitshöhe.

241
00:12:08,000 --> 00:12:12,000
Start der Suche nach Lecks erst nach Ihrem Programm richtig funktioniert,

242
00:12:12,000 --> 00:12:14,000
ohne weitere Fehler.

243
00:12:14,000 --> 00:12:16,000
>> Und das ist alles, was wir für dieses Video bekommen habe.

244
00:12:16,000 --> 00:12:18,000
Nun, was wartest du noch?

245
00:12:18,000 --> 00:12:21,000
Gehe laufen Valgrind auf Ihren Programmen richtig.

246
00:12:21,000 --> 00:12:25,000
Mein Name ist Nate Hardison. Dies ist CS50. [CS50.TV]