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

3
00:00:05,000 --> 00:00:07,000
Ini adalah CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
Beberapa bug yang paling sulit dalam program C

5
00:00:10,000 --> 00:00:13,000
berasal dari salah urus memori.

6
00:00:13,000 --> 00:00:15,000
Ada sejumlah besar cara untuk mengacaukan segalanya,

7
00:00:15,000 --> 00:00:17,000
termasuk mengalokasikan jumlah yang salah dari memori,

8
00:00:17,000 --> 00:00:20,000
lupa untuk menginisialisasi variabel,

9
00:00:20,000 --> 00:00:23,000
menulis sebelum atau setelah akhir dari buffer,

10
00:00:23,000 --> 00:00:25,000
dan membebaskan menjaga kali memori beberapa.

11
00:00:25,000 --> 00:00:28,000
Gejala berkisar dari crash intermiten

12
00:00:28,000 --> 00:00:30,000
nilai-nilai misterius ditimpa,

13
00:00:30,000 --> 00:00:34,000
sering pada tempat dan waktu jauh dari kesalahan aslinya.

14
00:00:34,000 --> 00:00:37,000
Menelusuri masalah diamati kembali ke akar penyebab yang mendasari

15
00:00:37,000 --> 00:00:39,000
dapat menantang,

16
00:00:39,000 --> 00:00:42,000
tapi untungnya ada program membantu disebut Valgrind

17
00:00:42,000 --> 00:00:44,000
yang dapat melakukan banyak hal untuk membantu.

18
00:00:44,000 --> 00:00:47,000
>> Anda menjalankan program di bawah Valgrind untuk mengaktifkan

19
00:00:47,000 --> 00:00:50,000
ekstensif memeriksa alokasi memori tumpukan dan akses.

20
00:00:50,000 --> 00:00:53,000
Ketika Valgrind mendeteksi masalah, itu memberikan Anda langsung,

21
00:00:53,000 --> 00:00:56,000
Informasi langsung yang memungkinkan Anda untuk

22
00:00:56,000 --> 00:00:58,000
lebih mudah menemukan dan memperbaiki masalah.

23
00:00:58,000 --> 00:01:01,000
Valgrind juga laporan tentang masalah memori kurang mematikan,

24
00:01:01,000 --> 00:01:04,000
seperti kebocoran memori, mengalokasikan memori heap,

25
00:01:04,000 --> 00:01:07,000
dan lupa untuk membebaskan itu.

26
00:01:07,000 --> 00:01:10,000
Seperti compiler kami, dentang, dalam debugger kami, GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind adalah perangkat lunak bebas, dan dipasang pada alat.

28
00:01:14,000 --> 00:01:16,000
Valgrind berjalan pada executable biner Anda,

29
00:01:16,000 --> 00:01:20,000
Anda tidak c atau. file sumber. kode h,

30
00:01:20,000 --> 00:01:23,000
jadi pastikan Anda telah mengumpulkan salinan up-to-date dari program Anda

31
00:01:23,000 --> 00:01:25,000
menggunakan dentang atau Membuat.

32
00:01:25,000 --> 00:01:28,000
Kemudian, menjalankan program Anda di bawah Valgrind dapat

33
00:01:28,000 --> 00:01:32,000
sesederhana hanya awalan perintah program standar dengan Valgrind kata,

34
00:01:32,000 --> 00:01:35,000
yang dijalankan Valgrind dan menjalankan program di dalamnya.

35
00:01:35,000 --> 00:01:38,000
Ketika mulai, Valgrind melakukan beberapa kompleks

36
00:01:38,000 --> 00:01:41,000
Sulap untuk mengkonfigurasi eksekusi untuk pemeriksaan memori,

37
00:01:41,000 --> 00:01:44,000
sehingga dapat mengambil sedikit untuk bangun dan berjalan.

38
00:01:44,000 --> 00:01:48,000
Program ini kemudian akan menjalankan normal, akan jauh lebih lambat,

39
00:01:48,000 --> 00:01:52,000
dan ketika selesai, Valgrind akan mencetak ringkasan penggunaan memori.

40
00:01:52,000 --> 00:01:58,000
Jika semua berjalan dengan baik, maka akan terlihat seperti ini:

41
00:01:58,000 --> 00:02:01,000
Dalam kasus ini, / clean_program.

42
00:02:01,000 --> 00:02:04,000
adalah path dari program yang saya ingin menjalankan.

43
00:02:04,000 --> 00:02:06,000
Dan sementara yang satu ini tidak mengambil argumen,

44
00:02:06,000 --> 00:02:09,000
jika hal itu aku baru saja taktik mereka ke akhir perintah seperti biasa.

45
00:02:09,000 --> 00:02:12,000
Program bersih hanyalah sebuah program kecil yang konyol saya buat

46
00:02:12,000 --> 00:02:15,000
yang mengalokasikan ruang untuk blok ints di heap,

47
00:02:15,000 --> 00:02:19,000
menempatkan beberapa nilai dalam diri mereka, dan membebaskan seluruh blok.

48
00:02:19,000 --> 00:02:23,000
Ini adalah apa yang Anda sedang syuting untuk, tidak ada kesalahan dan tidak ada kebocoran.

49
00:02:23,000 --> 00:02:27,000
>> Metrik lain yang penting adalah jumlah byte dialokasikan.

50
00:02:27,000 --> 00:02:32,000
Tergantung pada program tersebut, jika alokasi Anda berada di megabyte atau lebih tinggi,

51
00:02:32,000 --> 00:02:34,000
Anda mungkin melakukan sesuatu yang salah.

52
00:02:34,000 --> 00:02:37,000
Apakah Anda tidak perlu menyimpan duplikat?

53
00:02:37,000 --> 00:02:40,000
Apakah Anda menggunakan tumpukan untuk penyimpanan, ketika itu akan lebih baik untuk menggunakan stack?

54
00:02:40,000 --> 00:02:43,000
Jadi, kesalahan memori dapat benar-benar jahat.

55
00:02:43,000 --> 00:02:46,000
Yang lebih jelas menyebabkan crash spektakuler,

56
00:02:46,000 --> 00:02:49,000
tetapi itu pun masih akan sulit untuk menentukan

57
00:02:49,000 --> 00:02:51,000
apa sebenarnya menyebabkan kecelakaan.

58
00:02:51,000 --> 00:02:54,000
Lebih diam-diam, sebuah program dengan kesalahan memori

59
00:02:54,000 --> 00:02:56,000
masih bisa mengkompilasi bersih

60
00:02:56,000 --> 00:02:58,000
dan masih bisa bekerja dengan benar

61
00:02:58,000 --> 00:03:01,000
karena Anda berhasil mendapatkan beruntung sebagian besar waktu.

62
00:03:01,000 --> 00:03:04,000
Setelah beberapa "hasil yang sukses,"

63
00:03:04,000 --> 00:03:07,000
Anda mungkin hanya berpikir bahwa kecelakaan adalah kebetulan dari komputer,

64
00:03:07,000 --> 00:03:10,000
tapi komputer tidak pernah salah.

65
00:03:10,000 --> 00:03:13,000
>> Menjalankan Valgrind dapat membantu Anda melacak penyebab kesalahan memori terlihat

66
00:03:13,000 --> 00:03:18,000
serta menemukan mengintai kesalahan Anda bahkan tidak tahu tentang belum.

67
00:03:18,000 --> 00:03:22,000
Setiap kali Valgrind mendeteksi masalah, mencetak informasi tentang apa yang diamati.

68
00:03:22,000 --> 00:03:24,000
Setiap item cukup singkat -

69
00:03:24,000 --> 00:03:27,000
garis sumber instruksi menyinggung, apa masalah ini,

70
00:03:27,000 --> 00:03:30,000
dan sedikit info tentang memori yang terlibat -

71
00:03:30,000 --> 00:03:34,000
tetapi sering itu informasi yang cukup untuk mengarahkan perhatian Anda ke tempat yang tepat.

72
00:03:34,000 --> 00:03:37,000
Berikut adalah contoh dari Valgrind berjalan pada program kereta

73
00:03:37,000 --> 00:03:40,000
yang melakukan bacaan yang valid dari memori tumpukan.

74
00:03:40,000 --> 00:03:49,000
Kami melihat tidak ada kesalahan atau peringatan dalam kompilasi.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, ringkasan kesalahan mengatakan bahwa ada dua kesalahan -

76
00:03:53,000 --> 00:03:56,000
dua valid dibaca ukuran 4 - byte, yaitu.

77
00:03:56,000 --> 00:04:01,000
Kedua buruk membaca terjadi dalam fungsi utama invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
yang pertama pada baris 16 dan kedua pada baris 19.

79
00:04:04,000 --> 00:04:06,000
Mari kita lihat kode.

80
00:04:06,000 --> 00:04:11,000
Sepertinya panggilan pertama untuk printf mencoba untuk membaca satu int melewati ujung blok memori kita.

81
00:04:11,000 --> 00:04:13,000
Jika kita melihat kembali pada output Valgrind itu,

82
00:04:13,000 --> 00:04:16,000
kita melihat bahwa Valgrind memberitahu kami persis seperti itu.

83
00:04:16,000 --> 00:04:19,000
Alamat kami mencoba untuk membaca mulai 0 byte

84
00:04:19,000 --> 00:04:22,000
melewati ujung blok ukuran 16 byte -

85
00:04:22,000 --> 00:04:25,000
empat 32-bit ints yang kita dialokasikan.

86
00:04:25,000 --> 00:04:29,000
Artinya, alamat kami mencoba membaca dimulai tepat di ujung blok kami,

87
00:04:29,000 --> 00:04:32,000
seperti kita lihat dalam panggilan yang buruk printf kami.

88
00:04:32,000 --> 00:04:36,000
Sekarang, tidak valid dibaca mungkin tidak terlihat seperti itu masalah besar,

89
00:04:36,000 --> 00:04:39,000
tetapi jika Anda menggunakan data tersebut untuk mengontrol aliran program anda -

90
00:04:39,000 --> 00:04:42,000
Misalnya, sebagai bagian dari jika pernyataan atau loop -

91
00:04:42,000 --> 00:04:45,000
maka hal-hal diam-diam bisa pergi buruk.

92
00:04:45,000 --> 00:04:47,000
Perhatikan bagaimana saya bisa menjalankan program invalid_read

93
00:04:47,000 --> 00:04:50,000
dan tidak ada yang luar biasa terjadi.

94
00:04:50,000 --> 00:04:52,000
Menakutkan, ya?

95
00:04:52,000 --> 00:04:56,000
>> Sekarang, mari kita lihat jenis lagi kesalahan yang mungkin Anda alami dalam kode Anda,

96
00:04:56,000 --> 00:04:59,000
dan kita akan melihat bagaimana Valgrind mendeteksi mereka.

97
00:04:59,000 --> 00:05:01,000
Kami hanya melihat contoh sebuah invalid_read,

98
00:05:01,000 --> 00:05:04,000
jadi sekarang mari kita periksa invalid_write suatu.

99
00:05:04,000 --> 00:05:09,000
Sekali lagi, tidak ada kesalahan atau peringatan dalam kompilasi.

100
00:05:09,000 --> 00:05:12,000
Oke, Valgrind mengatakan bahwa ada dua kesalahan dalam program ini -

101
00:05:12,000 --> 00:05:15,000
dan invalid_write dan invalid_read sebuah.

102
00:05:15,000 --> 00:05:18,000
Mari kita periksa kode ini.

103
00:05:18,000 --> 00:05:21,000
Sepertinya kita punya sebuah instance dari strlen klasik ditambah satu bug.

104
00:05:21,000 --> 00:05:24,000
Kode tidak malloc byte ekstra ruang

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

106
00:05:26,000 --> 00:05:30,000
jadi ketika copy str pergi untuk menulis itu di ssubstrlen "cs50 rocks!"

107
00:05:30,000 --> 00:05:33,000
itu aja 1 byte melewati ujung blok kami.

108
00:05:33,000 --> 00:05:36,000
Invalid_read datang ketika kita melakukan panggilan kita untuk printf.

109
00:05:36,000 --> 00:05:40,000
Printf berakhir membaca memori yang tidak valid ketika membaca / 0 karakter

110
00:05:40,000 --> 00:05:43,000
seperti yang terlihat pada akhir string E itu pencetakan.

111
00:05:43,000 --> 00:05:45,000
Tapi semua ini lolos Valgrind.

112
00:05:45,000 --> 00:05:48,000
Kami melihat bahwa itu tertangkap invalid_write sebagai bagian dari salinan str

113
00:05:48,000 --> 00:05:51,000
on line 11 main, dan invalid_read adalah bagian dari printf.

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

115
00:05:54,000 --> 00:05:57,000
Sekali lagi, ini mungkin tidak tampak seperti masalah besar.

116
00:05:57,000 --> 00:06:00,000
Kita dapat menjalankan program ini berulang luar Valgrind

117
00:06:00,000 --> 00:06:03,000
dan tidak melihat gejala kesalahan.

118
00:06:03,000 --> 00:06:06,000
>> Namun, mari kita lihat sedikit variasi dari ini untuk melihat

119
00:06:06,000 --> 00:06:09,000
bagaimana hal-hal bisa benar-benar buruk.

120
00:06:09,000 --> 00:06:14,000
Jadi, diberikan, kita menyalahgunakan hal-hal lebih dari hanya sedikit dalam kode ini.

121
00:06:14,000 --> 00:06:17,000
Kami hanya mengalokasikan ruang di heap untuk dua string

122
00:06:17,000 --> 00:06:19,000
panjang cs50 batu,

123
00:06:19,000 --> 00:06:22,000
saat ini, mengingat / 0 karakter.

124
00:06:22,000 --> 00:06:25,000
Tapi kemudian kami melempar string super-panjang ke dalam blok memori

125
00:06:25,000 --> 00:06:27,000
S yang menunjuk ke.

126
00:06:27,000 --> 00:06:30,000
Apa efek yang akan yang memiliki di blok memori yang menunjuk T untuk?

127
00:06:30,000 --> 00:06:34,000
Nah, jika poin T untuk memori yang hanya berbatasan dengan S,

128
00:06:34,000 --> 00:06:37,000
datang hanya setelah itu,

129
00:06:37,000 --> 00:06:39,000
maka kita mungkin telah ditulis di atas bagian dari T.

130
00:06:39,000 --> 00:06:41,000
Mari kita menjalankan kode ini.

131
00:06:41,000 --> 00:06:43,000
Lihatlah apa yang terjadi.

132
00:06:43,000 --> 00:06:47,000
Senar kita disimpan dalam blok tumpukan kami baik tampaknya telah dicetak dengan benar.

133
00:06:47,000 --> 00:06:49,000
Sepertinya tidak ada yang salah sama sekali.

134
00:06:49,000 --> 00:06:52,000
Namun, mari kita kembali ke dalam kode dan

135
00:06:52,000 --> 00:06:55,000
komentar dari baris di mana kita copy cs50 batu

136
00:06:55,000 --> 00:06:59,000
ke blok memori kedua, ditunjuk oleh t.

137
00:06:59,000 --> 00:07:02,000
Sekarang, ketika kita menjalankan kode ini kita harus

138
00:07:02,000 --> 00:07:06,000
hanya melihat isi dari blok memori pertama mencetak.

139
00:07:06,000 --> 00:07:09,000
Whoa, meskipun kita tidak copy str

140
00:07:09,000 --> 00:07:12,000
setiap karakter ke dalam blok tumpukan kedua, yang ditunjuk oleh T,

141
00:07:12,000 --> 00:07:15,000
kita mendapatkan print out.

142
00:07:15,000 --> 00:07:18,000
Memang, string kita dimasukkan ke blok pertama kami

143
00:07:18,000 --> 00:07:21,000
menyerbu blok pertama dan ke blok kedua,

144
00:07:21,000 --> 00:07:23,000
membuat segalanya tampak normal.

145
00:07:23,000 --> 00:07:26,000
Valgrind, meskipun, menceritakan kisah nyata.

146
00:07:26,000 --> 00:07:28,000
Di sana kami pergi.

147
00:07:28,000 --> 00:07:32,000
Semua itu tidak valid membaca dan menulis.

148
00:07:32,000 --> 00:07:36,000
>> Mari kita lihat contoh lain jenis kesalahan.

149
00:07:36,000 --> 00:07:39,000
Di sini kita melakukan sesuatu yang agak disayangkan.

150
00:07:39,000 --> 00:07:41,000
Kami ambil ruang untuk int di heap,

151
00:07:41,000 --> 00:07:45,000
dan kita menginisialisasi sebuah pointer int - p - untuk menunjuk ke ruang tersebut.

152
00:07:45,000 --> 00:07:48,000
Namun, sementara kami pointer diinisialisasi,

153
00:07:48,000 --> 00:07:52,000
data bahwa itu menunjuk hanya telah apapun sampah adalah di bagian tumpukan.

154
00:07:52,000 --> 00:07:55,000
Jadi ketika kita memuat data ke int i,

155
00:07:55,000 --> 00:07:57,000
kita secara teknis menginisialisasi i,

156
00:07:57,000 --> 00:08:00,000
tapi kami melakukannya dengan data sampah.

157
00:08:00,000 --> 00:08:03,000
Panggilan untuk menegaskan, yang merupakan makro debugging berguna

158
00:08:03,000 --> 00:08:06,000
didefinisikan dalam perpustakaan menegaskan aptly bernama,

159
00:08:06,000 --> 00:08:09,000
akan membatalkan program jika kondisi pengujian yang gagal.

160
00:08:09,000 --> 00:08:11,000
Artinya, jika saya tidak 0.

161
00:08:11,000 --> 00:08:14,000
Tergantung pada apa yang ada di ruang tumpukan, ditunjuk oleh p,

162
00:08:14,000 --> 00:08:18,000
Program ini bisa bekerja kadang-kadang dan gagal di lain waktu.

163
00:08:18,000 --> 00:08:20,000
Jika berhasil, kita hanya mendapatkan beruntung.

164
00:08:20,000 --> 00:08:24,000
Compiler tidak akan menangkap kesalahan ini, tapi Valgrind kehendak yakin.

165
00:08:24,000 --> 00:08:28,000
Di sana kita melihat kesalahan yang berasal dari penggunaan kami data sampah.

166
00:08:28,000 --> 00:08:32,000
>> Bila Anda mengalokasikan memori heap tetapi tidak DEALLOCATE atau membebaskannya,

167
00:08:32,000 --> 00:08:34,000
yang disebut kebocoran.

168
00:08:34,000 --> 00:08:37,000
Untuk program, kecil berumur pendek yang berjalan dan segera keluar,

169
00:08:37,000 --> 00:08:39,000
kebocoran cukup berbahaya,

170
00:08:39,000 --> 00:08:42,000
tapi untuk proyek ukuran yang lebih besar dan / atau umur panjang,

171
00:08:42,000 --> 00:08:46,000
bahkan kebocoran kecil dapat senyawa menjadi sesuatu yang besar.

172
00:08:46,000 --> 00:08:49,000
Untuk CS50, kami mengharapkan Anda untuk

173
00:08:49,000 --> 00:08:51,000
mengurus membebaskan semua memori tumpukan yang Anda mengalokasikan,

174
00:08:51,000 --> 00:08:54,000
karena kami ingin Anda untuk membangun keterampilan untuk benar menangani proses manual

175
00:08:54,000 --> 00:08:56,000
dibutuhkan oleh C.

176
00:08:56,000 --> 00:08:59,000
Untuk melakukannya, program Anda harus memiliki tepat

177
00:08:59,000 --> 00:09:03,000
satu-ke-satu korespondensi antara malloc dan panggilan gratis.

178
00:09:03,000 --> 00:09:06,000
Untungnya, Valgrind dapat membantu Anda dengan kebocoran memori juga.

179
00:09:06,000 --> 00:09:09,000
Berikut ini adalah sebuah program yang disebut bocor leak.c yang mengalokasikan

180
00:09:09,000 --> 00:09:13,000
ruang di heap, menulis untuk itu, tetapi tidak membebaskannya.

181
00:09:13,000 --> 00:09:16,000
Kami compile dengan Membuat dan menjalankannya di bawah Valgrind,

182
00:09:16,000 --> 00:09:18,000
dan kita melihat bahwa, sementara kita tidak memiliki kesalahan memori,

183
00:09:18,000 --> 00:09:20,000
kita memiliki satu kebocoran.

184
00:09:20,000 --> 00:09:23,000
Ada 16 byte pasti hilang,

185
00:09:23,000 --> 00:09:27,000
yang berarti bahwa pointer ke memori yang tidak dalam lingkup saat program keluar.

186
00:09:27,000 --> 00:09:30,000
Sekarang, Valgrind tidak memberi kita satu ton informasi tentang kebocoran,

187
00:09:30,000 --> 00:09:35,000
tetapi jika kita mengikuti catatan kecil yang memberikan turun ke bagian bawah laporannya

188
00:09:35,000 --> 00:09:38,000
untuk mengulangi dengan - kebocoran-cek penuh =

189
00:09:38,000 --> 00:09:41,000
untuk melihat rincian lengkap dari memori bocor,

190
00:09:41,000 --> 00:09:44,000
kita akan mendapatkan informasi lebih lanjut.

191
00:09:44,000 --> 00:09:46,000
Sekarang, dalam ringkasan tumpukan,

192
00:09:46,000 --> 00:09:50,000
Valgrind memberitahu kita di mana memori yang hilang awalnya dialokasikan.

193
00:09:50,000 --> 00:09:52,000
Sama seperti yang kita tahu dari melihat dalam kode sumber,

194
00:09:52,000 --> 00:09:55,000
Valgrind memberitahu kita bahwa kita bocor memori

195
00:09:55,000 --> 00:09:58,000
dialokasikan dengan panggilan untuk malloc on line 8 dari leak.c

196
00:09:58,000 --> 00:10:00,000
dalam fungsi utama.

197
00:10:00,000 --> 00:10:02,000
Cukup bagus.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind mengkategorikan kebocoran menggunakan istilah-istilah ini:

199
00:10:04,000 --> 00:10:07,000
Pasti hilang - ini adalah memori yang dialokasikan heap

200
00:10:07,000 --> 00:10:10,000
yang program tidak lagi memiliki pointer.

201
00:10:10,000 --> 00:10:14,000
Valgrind tahu bahwa Anda pernah memiliki pointer tetapi sejak kehilangan jejak itu.

202
00:10:14,000 --> 00:10:17,000
Memori ini pasti bocor.

203
00:10:17,000 --> 00:10:20,000
Secara tidak langsung hilang - ini adalah memori yang dialokasikan heap

204
00:10:20,000 --> 00:10:24,000
dimana pointer hanya untuk itu juga hilang.

205
00:10:24,000 --> 00:10:27,000
Misalnya, jika Anda kehilangan pointer Anda ke simpul pertama dari linked list,

206
00:10:27,000 --> 00:10:30,000
maka node pertama itu sendiri akan benar-benar hilang,

207
00:10:30,000 --> 00:10:34,000
sementara setiap node berikutnya akan langsung hilang.

208
00:10:34,000 --> 00:10:37,000
Mungkin hilang - ini adalah memori yang dialokasikan heap

209
00:10:37,000 --> 00:10:41,000
yang Valgrind tidak dapat memastikan apakah ada pointer atau tidak.

210
00:10:41,000 --> 00:10:44,000
Masih terjangkau adalah memori yang dialokasikan heap

211
00:10:44,000 --> 00:10:47,000
yang program ini masih memiliki pointer di pintu keluar,

212
00:10:47,000 --> 00:10:50,000
yang biasanya berarti bahwa poin variabel global untuk itu.

213
00:10:50,000 --> 00:10:53,000
Untuk memeriksa kebocoran tersebut, Anda juga harus menyertakan opsi

214
00:10:53,000 --> 00:10:55,000
- Masih terjangkau = yes

215
00:10:55,000 --> 00:10:58,000
dalam doa Anda Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Kasus-kasus yang berbeda mungkin memerlukan strategi yang berbeda untuk membersihkan mereka,

217
00:11:01,000 --> 00:11:05,000
namun kebocoran harus dihilangkan.

218
00:11:05,000 --> 00:11:08,000
Sayangnya, memperbaiki kebocoran bisa sulit untuk dilakukan,

219
00:11:08,000 --> 00:11:11,000
karena panggilan tidak benar untuk membebaskan dapat meledakkan program Anda.

220
00:11:11,000 --> 00:11:14,000
Sebagai contoh, jika kita melihat invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
kita melihat contoh dealokasi memori buruk.

222
00:11:18,000 --> 00:11:21,000
Apa yang harus menjadi satu panggilan untuk membebaskan seluruh blok

223
00:11:21,000 --> 00:11:24,000
dari memori yang ditunjuk oleh int_block,

224
00:11:24,000 --> 00:11:27,000
malah menjadi upaya untuk membebaskan setiap bagian int berukuran

225
00:11:27,000 --> 00:11:29,000
dari memori individual.

226
00:11:29,000 --> 00:11:32,000
Ini akan gagal serempak.

227
00:11:32,000 --> 00:11:34,000
Boom! Apa kesalahan.

228
00:11:34,000 --> 00:11:36,000
Ini jelas tidak baik.

229
00:11:36,000 --> 00:11:39,000
Jika Anda terjebak dengan jenis kesalahan ini, meskipun, dan Anda tidak tahu di mana mencarinya,

230
00:11:39,000 --> 00:11:41,000
jatuh kembali pada teman baru terbaik Anda.

231
00:11:41,000 --> 00:11:44,000
Anda dapat menebaknya - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, seperti biasa, tahu persis apa yang terjadi.

233
00:11:47,000 --> 00:11:50,000
Penghitungan alokasi dan bebas tidak cocok.

234
00:11:50,000 --> 00:11:52,000
Kami punya 1 alloc dan 4 membebaskan.

235
00:11:52,000 --> 00:11:55,000
Dan Valgrind juga memberitahu kita di mana panggilan bebas pertama yang buruk -

236
00:11:55,000 --> 00:11:58,000
salah satu yang memicu blowup - adalah berasal dari -

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

238
00:12:00,000 --> 00:12:03,000
Seperti yang Anda lihat, panggilan buruk untuk membebaskan benar-benar buruk,

239
00:12:03,000 --> 00:12:05,000
jadi kami sarankan membiarkan kebocoran program Anda

240
00:12:05,000 --> 00:12:08,000
saat Anda sedang bekerja untuk mendapatkan fungsi yang benar.

241
00:12:08,000 --> 00:12:12,000
Mulai mencari kebocoran hanya setelah program Anda bekerja dengan benar,

242
00:12:12,000 --> 00:12:14,000
tanpa kesalahan lainnya.

243
00:12:14,000 --> 00:12:16,000
>> Dan itu yang kita punya untuk video ini.

244
00:12:16,000 --> 00:12:18,000
Sekarang apa yang Anda tunggu?

245
00:12:18,000 --> 00:12:21,000
Pergi menjalankan Valgrind pada program Anda sekarang.

246
00:12:21,000 --> 00:12:25,000
Nama saya adalah Nate Hardison. Ini adalah CS50. [CS50.TV]