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

4
00:00:07,000 --> 00:00:10,000
Niektóre z najtrudniejszych błędów w programach C

5
00:00:10,000 --> 00:00:13,000
pochodzić od złego zarządzania pamięcią.

6
00:00:13,000 --> 00:00:15,000
Istnieje ogromna ilość sposobów zepsuć rzeczy,

7
00:00:15,000 --> 00:00:17,000
w tym przydziału złą ilość pamięci,

8
00:00:17,000 --> 00:00:20,000
zapominając zainicjować zmienne,

9
00:00:20,000 --> 00:00:23,000
zapisu przed lub po zakończeniu bufora

10
00:00:23,000 --> 00:00:25,000
i uwolnienie zachować pamięci wiele razy.

11
00:00:25,000 --> 00:00:28,000
Objawy wahają się od nagłych załamań

12
00:00:28,000 --> 00:00:30,000
do wartości tajemniczo nadpisany,

13
00:00:30,000 --> 00:00:34,000
często w miejscach i czasach odległych od pierwotnego błędu.

14
00:00:34,000 --> 00:00:37,000
Śledzenia obserwowanego problemu z powrotem do przyczyny głównej

15
00:00:37,000 --> 00:00:39,000
może być trudne,

16
00:00:39,000 --> 00:00:42,000
ale na szczęście jest to bardzo pomocny program o nazwie Valgrind

17
00:00:42,000 --> 00:00:44,000
że można zrobić wiele, aby pomóc.

18
00:00:44,000 --> 00:00:47,000
>> Uruchomić program pod Valgrind aby umożliwić

19
00:00:47,000 --> 00:00:50,000
rozległe sprawdzenie alokacji pamięci sterty i dostępów.

20
00:00:50,000 --> 00:00:53,000
Kiedy Valgrind wykryje problem, daje natychmiastowe,

21
00:00:53,000 --> 00:00:56,000
bezpośrednie informacje, które pozwala na

22
00:00:56,000 --> 00:00:58,000
łatwiej znaleźć i rozwiązać problem.

23
00:00:58,000 --> 00:01:01,000
Valgrind również raporty na temat śmiertelnych mniej problemów z pamięcią,

24
00:01:01,000 --> 00:01:04,000
takie jak wycieki pamięci, przydział pamięci sterty,

25
00:01:04,000 --> 00:01:07,000
i zapominając, aby uwolnić ją.

26
00:01:07,000 --> 00:01:10,000
Jak nasz kompilator, dzyń, w naszym debugger, GDB

27
00:01:10,000 --> 00:01:14,000
Valgrind jest wolne oprogramowanie i jest zainstalowany na urządzeniu.

28
00:01:14,000 --> 00:01:16,000
Valgrind działa na pliku binarnym,

29
00:01:16,000 --> 00:01:20,000
nie twój. c lub pliki. h kod źródłowy,

30
00:01:20,000 --> 00:01:23,000
więc upewnij się, że sporządziła up-to-date kopii programu

31
00:01:23,000 --> 00:01:25,000
używając dzyń lub Make.

32
00:01:25,000 --> 00:01:28,000
Następnie uruchomić program pod Valgrind może być

33
00:01:28,000 --> 00:01:32,000
tak proste, jak tylko poprzedzania standardowe polecenie programu z Valgrind słownego,

34
00:01:32,000 --> 00:01:35,000
który zaczyna się Valgrind oraz uruchamia program w środku.

35
00:01:35,000 --> 00:01:38,000
Przy uruchamianiu Valgrind robi jakiś kompleks

36
00:01:38,000 --> 00:01:41,000
jiggering skonfigurować plik wykonywalny do kontroli pamięci,

37
00:01:41,000 --> 00:01:44,000
więc może to zająć trochę się i działa.

38
00:01:44,000 --> 00:01:48,000
Program następnie wykonywać normalnie, czy to o wiele wolniej,

39
00:01:48,000 --> 00:01:52,000
i kiedy to się zakończy, Valgrind wydrukuje podsumowanie jego użycia pamięci.

40
00:01:52,000 --> 00:01:58,000
Jeśli wszystko pójdzie dobrze, będzie to wyglądać mniej więcej tak:

41
00:01:58,000 --> 00:02:01,000
W tym przypadku,. / Clean_program

42
00:02:01,000 --> 00:02:04,000
to ścieżka do programu chcę uruchomić.

43
00:02:04,000 --> 00:02:06,000
A gdy ten nie podejmuje żadnych argumentów,

44
00:02:06,000 --> 00:02:09,000
Jeśli to nie tylko, że że ich przyczepność do końca, jak zwykle polecenia.

45
00:02:09,000 --> 00:02:12,000
Clean program jest tylko głupi mały program stworzyłem

46
00:02:12,000 --> 00:02:15,000
który przydziela miejsca na bloku wskazówki na stercie,

47
00:02:15,000 --> 00:02:19,000
umieścić kilka wartości w nich, i uwalnia cały blok.

48
00:02:19,000 --> 00:02:23,000
To jest to, co fotografujesz za, bez błędów i bez wycieków.

49
00:02:23,000 --> 00:02:27,000
>> Innym ważnym metryka jest całkowita liczba bajtów przydzielone.

50
00:02:27,000 --> 00:02:32,000
W zależności od programu, jeśli przydziały są w megabajtach lub wyższym,

51
00:02:32,000 --> 00:02:34,000
pewnie robi coś złego.

52
00:02:34,000 --> 00:02:37,000
Czy niepotrzebnie przechowywania duplikatów?

53
00:02:37,000 --> 00:02:40,000
Używasz sterty do przechowywania, kiedy lepiej byłoby użyć stos?

54
00:02:40,000 --> 00:02:43,000
Tak, błędy pamięci mogą być naprawdę zła.

55
00:02:43,000 --> 00:02:46,000
Im bardziej jawne te powodują spektakularne awarie,

56
00:02:46,000 --> 00:02:49,000
ale nawet wtedy może być nadal trudno wskazać

57
00:02:49,000 --> 00:02:51,000
co dokładnie doprowadziło do katastrofy.

58
00:02:51,000 --> 00:02:54,000
Bardziej podstępnie program z błędem pamięci

59
00:02:54,000 --> 00:02:56,000
może jeszcze skompilować czysto

60
00:02:56,000 --> 00:02:58,000
i wciąż wydaje się działać poprawnie

61
00:02:58,000 --> 00:03:01,000
ponieważ udało się na szczęście większość czasu.

62
00:03:01,000 --> 00:03:04,000
Po kilku udanych rezultatów ","

63
00:03:04,000 --> 00:03:07,000
może po prostu uważam, że katastrofa jest fuks z komputera,

64
00:03:07,000 --> 00:03:10,000
ale komputer nigdy nie jest źle.

65
00:03:10,000 --> 00:03:13,000
>> Bieganie Valgrind pomaga wyśledzić przyczynę widocznych błędów pamięci

66
00:03:13,000 --> 00:03:18,000
jak również znaleźć czai błędy nawet nie jeszcze wiedzieć.

67
00:03:18,000 --> 00:03:22,000
Każdorazowo Valgrind wykryje problem, drukuje informacje o tym co to przestrzegane.

68
00:03:22,000 --> 00:03:24,000
Każda pozycja jest dość lakoniczny -

69
00:03:24,000 --> 00:03:27,000
linia źródło instrukcji nagannego, co kwestią jest

70
00:03:27,000 --> 00:03:30,000
i trochę informacji o danej pamięci -

71
00:03:30,000 --> 00:03:34,000
ale często jest to wystarczająco dużo informacji, aby skierować uwagę na właściwym miejscu.

72
00:03:34,000 --> 00:03:37,000
Oto przykład z Valgrind uruchomiony na buggy programu

73
00:03:37,000 --> 00:03:40,000
które wykonuje nieprawidłową odczytu pamięci sterty.

74
00:03:40,000 --> 00:03:49,000
Nie widzimy żadnych błędów ani ostrzeżeń w kompilacji.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, summary błąd mówi, że są dwa błędy -

76
00:03:53,000 --> 00:03:56,000
dwa nieważne odsłon wielkości 4 - bajty, że jest.

77
00:03:56,000 --> 00:04:01,000
Zarówno źle odczytuje wystąpił w głównej funkcji invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
najpierw na linii 16 i sekund na linii 19.

79
00:04:04,000 --> 00:04:06,000
Spójrzmy na kod.

80
00:04:06,000 --> 00:04:11,000
Wygląda tak, jak na pierwsze zaproszenie do printf próbuje czytać int przeszłość koniec naszego bloku pamięci.

81
00:04:11,000 --> 00:04:13,000
Jeśli spojrzymy na wyjściu Valgrind jest,

82
00:04:13,000 --> 00:04:16,000
widzimy, że Valgrind powiedział nam dokładnie to.

83
00:04:16,000 --> 00:04:19,000
Adres próbujemy czytać zaczyna 0 bajtów

84
00:04:19,000 --> 00:04:22,000
poza końcem bloku wielkości - 16 bajtów

85
00:04:22,000 --> 00:04:25,000
cztery 32-bitowe ints że przydzielone.

86
00:04:25,000 --> 00:04:29,000
Oznacza to, że adres staraliśmy odczytu rozpoczyna się na końcu naszego bloku

87
00:04:29,000 --> 00:04:32,000
jak widzimy w naszym złym rozmowy printf.

88
00:04:32,000 --> 00:04:36,000
Teraz nieważne odsłon nie wydaje się, że nic wielkiego,

89
00:04:36,000 --> 00:04:39,000
ale jeśli używasz tych danych do sterowania przepływem programu -

90
00:04:39,000 --> 00:04:42,000
na przykład, jako część instrukcji if lub pętli -

91
00:04:42,000 --> 00:04:45,000
następnie rzeczy można dyskretnie iść źle.

92
00:04:45,000 --> 00:04:47,000
Zobacz, jak mogę uruchomić invalid_read programu

93
00:04:47,000 --> 00:04:50,000
i nic niezwykłego się nie dzieje.

94
00:04:50,000 --> 00:04:52,000
Straszne, co?

95
00:04:52,000 --> 00:04:56,000
>> Teraz spójrzmy na trochę więcej rodzajów błędów, które mogą wystąpić w kodzie,

96
00:04:56,000 --> 00:04:59,000
i zobaczymy jak Valgrind je wykrywa.

97
00:04:59,000 --> 00:05:01,000
Właśnie zobaczyłem przykładem invalid_read,

98
00:05:01,000 --> 00:05:04,000
więc teraz niech wyewidencjonować invalid_write.

99
00:05:04,000 --> 00:05:09,000
Ponownie, żadne błędy ani ostrzeżenia w kompilacji.

100
00:05:09,000 --> 00:05:12,000
Okay, Valgrind mówi, że są dwa błędy w tym programie -

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

102
00:05:15,000 --> 00:05:18,000
Sprawdźmy ten kod.

103
00:05:18,000 --> 00:05:21,000
Wygląda na to, że mamy wystąpienie klasycznego strlen plus jeden bug.

104
00:05:21,000 --> 00:05:24,000
Kod nie malloc dodatkowy bajt miejsca

105
00:05:24,000 --> 00:05:26,000
do / 0 charakteru,

106
00:05:26,000 --> 00:05:30,000
więc kiedy str kopia poszła do napisania go w ssubstrlen "CS50 skały!"

107
00:05:30,000 --> 00:05:33,000
napisał, 1 bajt poza końcem naszego bloku.

108
00:05:33,000 --> 00:05:36,000
Invalid_read przychodzi, gdy wykonujemy nasze wezwanie do printf.

109
00:05:36,000 --> 00:05:40,000
Printf kończy czytanie nieprawidłowy pamięci, gdy czyta / 0 znaków

110
00:05:40,000 --> 00:05:43,000
jak wygląda na końcu łańcucha E jest drukowanie.

111
00:05:43,000 --> 00:05:45,000
Ale nic z tego uciekł Valgrind.

112
00:05:45,000 --> 00:05:48,000
Widzimy, że złapał invalid_write jako części egzemplarza ul

113
00:05:48,000 --> 00:05:51,000
na linii 11 z głównym i invalid_read jest częścią printf.

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

115
00:05:54,000 --> 00:05:57,000
Ponownie, to nie wydaje się to nic wielkiego.

116
00:05:57,000 --> 00:06:00,000
Możemy uruchomić ten program w kółko poza Valgrind

117
00:06:00,000 --> 00:06:03,000
i nie widać żadnych objawów błędach.

118
00:06:03,000 --> 00:06:06,000
>> Jednak spójrzmy na niewielką zmienność to zobaczyć

119
00:06:06,000 --> 00:06:09,000
jak rzeczy mogą się naprawdę źle.

120
00:06:09,000 --> 00:06:14,000
Więc, przyznane nam nadużywają rzeczy więcej niż tylko nieco w tym kodzie.

121
00:06:14,000 --> 00:06:17,000
My tylko przydzielanie przestrzeni na stercie dla dwóch ciągów

122
00:06:17,000 --> 00:06:19,000
długość CS50 skał,

123
00:06:19,000 --> 00:06:22,000
tym razem, pamiętając / 0 charakter.

124
00:06:22,000 --> 00:06:25,000
Ale potem rzucamy w ciąg super-długie do bloku pamięci

125
00:06:25,000 --> 00:06:27,000
że S jest skierowany do.

126
00:06:27,000 --> 00:06:30,000
Jaki wpływ będzie, że mają na bloku pamięci, który wskazuje na T?

127
00:06:30,000 --> 00:06:34,000
Cóż, jeśli T wskazuje na pamięci, że jest po prostu obok S,

128
00:06:34,000 --> 00:06:37,000
przychodzi tylko po to,

129
00:06:37,000 --> 00:06:39,000
wówczas może pisaliśmy na części T.

130
00:06:39,000 --> 00:06:41,000
Przyjrzyjmy się ten kod.

131
00:06:41,000 --> 00:06:43,000
Spójrz na to, co się stało.

132
00:06:43,000 --> 00:06:47,000
Struny mamy zapisane w naszych blokach sterty obu pojawił się wydrukowane prawidłowo.

133
00:06:47,000 --> 00:06:49,000
Nic nie wydaje się w porządku w ogóle.

134
00:06:49,000 --> 00:06:52,000
Jednak wróćmy do naszego kodu i

135
00:06:52,000 --> 00:06:55,000
skomentuj linię gdzie skopiować CS50 skały

136
00:06:55,000 --> 00:06:59,000
do drugiego bloku pamięci, wskazywany przez t.

137
00:06:59,000 --> 00:07:02,000
Teraz, kiedy mamy ten kod powinniśmy

138
00:07:02,000 --> 00:07:06,000
zobaczyć tylko treść pierwszego bloku pamięci wydrukować.

139
00:07:06,000 --> 00:07:09,000
Whoa, choć nie str kopia

140
00:07:09,000 --> 00:07:12,000
żadnych znaków w drugim bloku sterty, wskazywany przez T,

141
00:07:12,000 --> 00:07:15,000
otrzymujemy wydruk.

142
00:07:15,000 --> 00:07:18,000
Istotnie, ciąg nadziewane do naszego pierwszego bloku

143
00:07:18,000 --> 00:07:21,000
zajęli pierwszy blok i do drugiego bloku,

144
00:07:21,000 --> 00:07:23,000
co wszystko wydaje się normalne.

145
00:07:23,000 --> 00:07:26,000
Valgrind, choć opowiada prawdziwą historię.

146
00:07:26,000 --> 00:07:28,000
Proszę bardzo.

147
00:07:28,000 --> 00:07:32,000
Wszystkie te nieważne czyta i pisze.

148
00:07:32,000 --> 00:07:36,000
>> Spójrzmy na przykład inny rodzaj błędu.

149
00:07:36,000 --> 00:07:39,000
Tutaj mamy coś zrobić raczej niefortunne.

150
00:07:39,000 --> 00:07:41,000
Łapiemy przestrzeń dla int na stercie,

151
00:07:41,000 --> 00:07:45,000
i zainicjować int wskaźnik - P - aby wskazywał na tej przestrzeni.

152
00:07:45,000 --> 00:07:48,000
Jednakże, podczas gdy nasz wskaźnik jest inicjowany,

153
00:07:48,000 --> 00:07:52,000
dane wskazujące, że jest to po prostu nie jest, co śmieci w tej części hałdy.

154
00:07:52,000 --> 00:07:55,000
Więc kiedy załadować te dane do int i,

155
00:07:55,000 --> 00:07:57,000
my technicznie zainicjować i,

156
00:07:57,000 --> 00:08:00,000
ale robimy to z danych śmieci.

157
00:08:00,000 --> 00:08:03,000
Wezwanie do dochodzenia, które jest przydatne makro debugowanie

158
00:08:03,000 --> 00:08:06,000
zdefiniowane w trafnie nazwanej dochodzić bibliotece

159
00:08:06,000 --> 00:08:09,000
przerwie programu, jeśli jego stan test nie powiedzie się.

160
00:08:09,000 --> 00:08:11,000
To jest, jeśli nie jest 0.

161
00:08:11,000 --> 00:08:14,000
W zależności od tego, co było w przestrzeni sterty, wskazywany przez p,

162
00:08:14,000 --> 00:08:18,000
ten program może działać, a czasami nie w innym czasie.

163
00:08:18,000 --> 00:08:20,000
Jeśli to działa, po prostu się szczęście.

164
00:08:20,000 --> 00:08:24,000
Kompilator nie będzie złapać ten błąd, ale Valgrind pewno.

165
00:08:24,000 --> 00:08:28,000
Widzimy tam błąd wynikający z naszego użycia tych danych śmieci.

166
00:08:28,000 --> 00:08:32,000
>> Podczas przydzielania pamięci sterty, ale nie zwalnianie go lub zwolnić go,

167
00:08:32,000 --> 00:08:34,000
że nazywa się wyciek.

168
00:08:34,000 --> 00:08:37,000
Na małym, krótko programie uruchamiającym i natychmiast wyjść,

169
00:08:37,000 --> 00:08:39,000
przecieki są dość nieszkodliwe,

170
00:08:39,000 --> 00:08:42,000
ale w przypadku projektu o większym rozmiarze i / lub długowieczności,

171
00:08:42,000 --> 00:08:46,000
nawet niewielka nieszczelność może spotęgować się w coś poważnego.

172
00:08:46,000 --> 00:08:49,000
Dla CS50, mamy oczekiwać na

173
00:08:49,000 --> 00:08:51,000
dbać o uwolnienie wszystkich pamięci sterty, które rozdzieli,

174
00:08:51,000 --> 00:08:54,000
ponieważ chcemy budować umiejętności prawidłowo obsługiwać proces ręcznej

175
00:08:54,000 --> 00:08:56,000
wymagane przez C.

176
00:08:56,000 --> 00:08:59,000
Aby to zrobić, program powinien mieć dokładny

177
00:08:59,000 --> 00:09:03,000
jeden do jednego między malloc i wzywa darmo.

178
00:09:03,000 --> 00:09:06,000
Na szczęście, Valgrind może pomóc wycieków pamięci też.

179
00:09:06,000 --> 00:09:09,000
Tutaj jest dziurawy program o nazwie leak.c przydzielaną

180
00:09:09,000 --> 00:09:13,000
Przestrzeń na stosie, to zapisuje się, ale nie zwalnia go.

181
00:09:13,000 --> 00:09:16,000
Tworzymy go z Marka i uruchomić pod Valgrind,

182
00:09:16,000 --> 00:09:18,000
i widzimy, że o ile nie mamy żadnych błędów związanych z pamięcią,

183
00:09:18,000 --> 00:09:20,000
to mamy jeden wyciek.

184
00:09:20,000 --> 00:09:23,000
Istnieje 16 bajtów na pewno zwycięstwo,

185
00:09:23,000 --> 00:09:27,000
co oznacza, że ​​w tym wskaźnik pamięci nie w zakresie, gdy program wyjściu.

186
00:09:27,000 --> 00:09:30,000
Teraz Valgrind nie daje nam mnóstwo informacji na temat wycieku,

187
00:09:30,000 --> 00:09:35,000
ale jeśli będziemy śledzić ten liścik, że daje w dół w kierunku dna raporcie

188
00:09:35,000 --> 00:09:38,000
ponownie uruchomić z - wyciek sprawdzić = full

189
00:09:38,000 --> 00:09:41,000
, aby zobaczyć pełne dane wyciekły pamięci

190
00:09:41,000 --> 00:09:44,000
będziemy mieć więcej informacji.

191
00:09:44,000 --> 00:09:46,000
Teraz, w podsumowaniu sterty

192
00:09:46,000 --> 00:09:50,000
Valgrind mówi nam, gdzie pamięć, która została utracona została wstępnie przydzielone.

193
00:09:50,000 --> 00:09:52,000
Tak jak wiemy, od patrzenia w kodzie źródłowym,

194
00:09:52,000 --> 00:09:55,000
Valgrind informuje nas, że wyciekły z pamięci

195
00:09:55,000 --> 00:09:58,000
przyznane z zaproszeniem do malloc na linii 8 z leak.c

196
00:09:58,000 --> 00:10:00,000
w głównej funkcji.

197
00:10:00,000 --> 00:10:02,000
Całkiem sprytne.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind kategoryzuje nieszczelności za pomocą tych terminów:

199
00:10:04,000 --> 00:10:07,000
Zdecydowanie porażka - to kupa przydzielonej pamięci

200
00:10:07,000 --> 00:10:10,000
Program do którego nie ma wskaźnika.

201
00:10:10,000 --> 00:10:14,000
Valgrind wie, że kiedyś miał wskaźnik ale od tego czasu straciłem go.

202
00:10:14,000 --> 00:10:17,000
Ta pamięć jest na pewno przeciekał.

203
00:10:17,000 --> 00:10:20,000
Pośrednio porażka - to kupa przydzielonej pamięci

204
00:10:20,000 --> 00:10:24,000
, do którego tylko do niego również wskaźniki są tracone.

205
00:10:24,000 --> 00:10:27,000
Na przykład, jeśli nie pamiętasz wskaźnik do pierwszego węzła połączonej listy,

206
00:10:27,000 --> 00:10:30,000
następnie pierwszy węzeł sam byłby zdecydowanie utracone,

207
00:10:30,000 --> 00:10:34,000
natomiast wszelkie kolejne węzły będą pośrednio utracone.

208
00:10:34,000 --> 00:10:37,000
Prawdopodobnie stracił - to kupa przydzielonej pamięci

209
00:10:37,000 --> 00:10:41,000
do których nie może być Valgrind się, czy jest to wskaźnik, czy nie.

210
00:10:41,000 --> 00:10:44,000
Wciąż dostępny jest kupa przydzielonej pamięci

211
00:10:44,000 --> 00:10:47,000
do którego program ma jeszcze wskaźnik na wyjściu,

212
00:10:47,000 --> 00:10:50,000
co zazwyczaj oznacza, że ​​zmienna globalna na niego wskazuje.

213
00:10:50,000 --> 00:10:53,000
Aby sprawdzić te nieszczelności, będziesz mieć również o możliwość

214
00:10:53,000 --> 00:10:55,000
- Wciąż osiągalny = yes

215
00:10:55,000 --> 00:10:58,000
w pw Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Te różne przypadki mogą wymagać różnych strategii do czyszczenia ich,

217
00:11:01,000 --> 00:11:05,000
ale nieszczelności powinny być wyeliminowane.

218
00:11:05,000 --> 00:11:08,000
Niestety, ustalenie wycieki mogą być trudne do zrobienia,

219
00:11:08,000 --> 00:11:11,000
ponieważ błędne połączenia darmo można wysadzić swój program.

220
00:11:11,000 --> 00:11:14,000
Na przykład, jeśli spojrzymy na invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
widzimy przykład złej dezalokacji pamięci.

222
00:11:18,000 --> 00:11:21,000
, Co powinno być pojedyncze wywołanie uwolnienia cały blok

223
00:11:21,000 --> 00:11:24,000
pamięci wskazywanego przez int_block,

224
00:11:24,000 --> 00:11:27,000
zamiast tego staje się próba zwolnienia każdy int wielkości punkt

225
00:11:27,000 --> 00:11:29,000
z pamięci indywidualnie.

226
00:11:29,000 --> 00:11:32,000
To nie katastrofalnie.

227
00:11:32,000 --> 00:11:34,000
Boom! Jaki błąd.

228
00:11:34,000 --> 00:11:36,000
To zdecydowanie nie jest dobry.

229
00:11:36,000 --> 00:11:39,000
Jeśli nie wiecie, z tego rodzaju błędów, choć i nie wiesz, gdzie szukać,

230
00:11:39,000 --> 00:11:41,000
spadnie z powrotem na swoim nowym najlepszym przyjacielem.

231
00:11:41,000 --> 00:11:44,000
Zgadłeś - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, jak zawsze, nie wie dokładnie, co się dzieje.

233
00:11:47,000 --> 00:11:50,000
W Alloc i wolne liczy nie pasują.

234
00:11:50,000 --> 00:11:52,000
Mamy 1 alloc i 4 zwalnia.

235
00:11:52,000 --> 00:11:55,000
I Valgrind mówi nam także, gdzie pierwsze złe wolne połączenie -

236
00:11:55,000 --> 00:11:58,000
który wywołał Blowup - pochodzi -

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

238
00:12:00,000 --> 00:12:03,000
Jak widać, złe połączenia na darmo są naprawdę złe,

239
00:12:03,000 --> 00:12:05,000
dlatego zalecamy pozwoleniem wyciek programu

240
00:12:05,000 --> 00:12:08,000
podczas pracy na uzyskanie funkcjonalności prawidłowe.

241
00:12:08,000 --> 00:12:12,000
Zacząć szukać przecieków tylko po program działa prawidłowo,

242
00:12:12,000 --> 00:12:14,000
bez żadnych innych błędów.

243
00:12:14,000 --> 00:12:16,000
>> I to wszystko, co mamy do tego filmu.

244
00:12:16,000 --> 00:12:18,000
Teraz co czekasz?

245
00:12:18,000 --> 00:12:21,000
Idź uruchomić Valgrind na programach teraz.

246
00:12:21,000 --> 00:12:25,000
Nazywam się Nate Hardison. To CS50. [CS50.TV]