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, Université de Harvard]

3
00:00:05,000 --> 00:00:07,000
C'est CS50, CS50.TV]

4
00:00:07,000 --> 00:00:10,000
Quelques-uns des bugs les plus difficiles dans les programmes C

5
00:00:10,000 --> 00:00:13,000
proviennent de la mauvaise gestion de la mémoire.

6
00:00:13,000 --> 00:00:15,000
Il ya un grand nombre de façons de visser les choses,

7
00:00:15,000 --> 00:00:17,000
en ce compris affecter un montant erroné de la mémoire,

8
00:00:17,000 --> 00:00:20,000
oublier d'initialiser les variables,

9
00:00:20,000 --> 00:00:23,000
l'écriture avant ou après la fin d'un tampon,

10
00:00:23,000 --> 00:00:25,000
et la libération de garder les temps de mémoire multiples.

11
00:00:25,000 --> 00:00:28,000
Les symptômes vont de plantages intermittents

12
00:00:28,000 --> 00:00:30,000
aux valeurs mystérieusement écrasés,

13
00:00:30,000 --> 00:00:34,000
souvent dans des lieux et des temps très éloignés de l'erreur initiale.

14
00:00:34,000 --> 00:00:37,000
Déterminer le problème observé remonter à la cause racine sous-jacente

15
00:00:37,000 --> 00:00:39,000
Il peut être difficile,

16
00:00:39,000 --> 00:00:42,000
mais heureusement, il ya un programme appelé Valgrind utile

17
00:00:42,000 --> 00:00:44,000
qui peut faire beaucoup pour aider.

18
00:00:44,000 --> 00:00:47,000
>> Vous exécutez un programme en vertu Valgrind pour permettre

19
00:00:47,000 --> 00:00:50,000
vérification approfondie des allocations de mémoire de tas et des accès.

20
00:00:50,000 --> 00:00:53,000
Lorsque Valgrind détecte un problème, il vous donne immédiatement,

21
00:00:53,000 --> 00:00:56,000
information directe qui vous permet de

22
00:00:56,000 --> 00:00:58,000
plus facilement trouver et corriger le problème.

23
00:00:58,000 --> 00:01:01,000
Valgrind également des rapports sur des problèmes de mémoire moins mortelles,

24
00:01:01,000 --> 00:01:04,000
telles que les fuites de mémoire, l'allocation de mémoire tas,

25
00:01:04,000 --> 00:01:07,000
et d'oublier de le libérer.

26
00:01:07,000 --> 00:01:10,000
Comme notre compilateur, Clang, dans notre débogueur GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind est un logiciel libre, et il est installé sur l'appareil.

28
00:01:14,000 --> 00:01:16,000
Valgrind s'exécute sur votre exécutable binaire,

29
00:01:16,000 --> 00:01:20,000
pas votre. c ou fichiers. h de code source,

30
00:01:20,000 --> 00:01:23,000
alors assurez-vous que vous avez compilé une copie mise à jour de votre programme

31
00:01:23,000 --> 00:01:25,000
en utilisant Clang Ou Faire.

32
00:01:25,000 --> 00:01:28,000
Ensuite, l'exécution de votre programme sous Valgrind peut être

33
00:01:28,000 --> 00:01:32,000
aussi simple que de précéder la commande de programme standard avec le mot Valgrind,

34
00:01:32,000 --> 00:01:35,000
qui démarre Valgrind et exécute le programme à l'intérieur de celui-ci.

35
00:01:35,000 --> 00:01:38,000
Lors du démarrage, Valgrind fait un peu complexe

36
00:01:38,000 --> 00:01:41,000
calibrage de configurer le fichier exécutable pour les vérifications de mémoire,

37
00:01:41,000 --> 00:01:44,000
donc cela peut prendre un peu pour se lever et courir.

38
00:01:44,000 --> 00:01:48,000
Le programme va alors s'exécuter normalement, que ce soit beaucoup plus lentement,

39
00:01:48,000 --> 00:01:52,000
et quand il sera fini, Valgrind affiche un résumé de son utilisation de la mémoire.

40
00:01:52,000 --> 00:01:58,000
Si tout va bien, il va ressembler à quelque chose comme ceci:

41
00:01:58,000 --> 00:02:01,000
Dans ce cas,. / Clean_program

42
00:02:01,000 --> 00:02:04,000
est le chemin d'accès au programme que je veux courir.

43
00:02:04,000 --> 00:02:06,000
Et tandis que celui-ci ne prend aucun argument,

44
00:02:06,000 --> 00:02:09,000
si c'était le cas je venais de les virer à la fin de la commande comme d'habitude.

45
00:02:09,000 --> 00:02:12,000
Programme Clean est juste un programme peu ridicule que j'ai créé

46
00:02:12,000 --> 00:02:15,000
qui alloue l'espace pour un bloc de ints sur le tas,

47
00:02:15,000 --> 00:02:19,000
mettre des valeurs à l'intérieur d'eux, et libère le bloc entier.

48
00:02:19,000 --> 00:02:23,000
C'est ce que vous filmez pour, aucune erreur et pas de fuites.

49
00:02:23,000 --> 00:02:27,000
>> Un autre indicateur important est le nombre total d'octets alloués.

50
00:02:27,000 --> 00:02:32,000
Selon le programme, si vos allocations sont les méga-octets ou plus,

51
00:02:32,000 --> 00:02:34,000
vous faites probablement quelque chose de mal.

52
00:02:34,000 --> 00:02:37,000
Êtes-vous stocker inutilement des doublons?

53
00:02:37,000 --> 00:02:40,000
Utilisez-vous le tas de stockage, alors qu'il serait préférable d'utiliser la pile?

54
00:02:40,000 --> 00:02:43,000
Ainsi, les erreurs de mémoire peut être vraiment mal.

55
00:02:43,000 --> 00:02:46,000
Les plus manifestes provoquer des accidents spectaculaires,

56
00:02:46,000 --> 00:02:49,000
mais même alors, il peut encore être difficile à cerner

57
00:02:49,000 --> 00:02:51,000
exactement ce qui a mené à l'accident.

58
00:02:51,000 --> 00:02:54,000
Plus insidieusement, un programme avec une erreur de mémoire

59
00:02:54,000 --> 00:02:56,000
pouvez toujours compiler proprement

60
00:02:56,000 --> 00:02:58,000
et peut encore semble pas fonctionner correctement

61
00:02:58,000 --> 00:03:01,000
parce que vous avez réussi à avoir de la chance la plupart du temps.

62
00:03:01,000 --> 00:03:04,000
Après plusieurs "bons résultats",

63
00:03:04,000 --> 00:03:07,000
vous pourriez penser qu'un accident est un coup de chance de l'ordinateur,

64
00:03:07,000 --> 00:03:10,000
mais l'ordinateur ne se trompe jamais.

65
00:03:10,000 --> 00:03:13,000
>> Exécution Valgrind peut vous aider à repérer la cause des erreurs de mémoire visibles

66
00:03:13,000 --> 00:03:18,000
ainsi que de trouver tapi erreurs que vous n'avez même pas encore au courant.

67
00:03:18,000 --> 00:03:22,000
Chaque fois que Valgrind détecte un problème, il affiche les informations à propos de ce qu'il a observé.

68
00:03:22,000 --> 00:03:24,000
Chaque élément est assez laconique -

69
00:03:24,000 --> 00:03:27,000
la ligne de source de l'instruction fautive, quel est le problème,

70
00:03:27,000 --> 00:03:30,000
et un peu d'info sur la mémoire impliqués -

71
00:03:30,000 --> 00:03:34,000
mais c'est souvent assez d'information pour attirer votre attention au bon endroit.

72
00:03:34,000 --> 00:03:37,000
Voici un exemple de Valgrind en cours d'exécution sur un programme bogué

73
00:03:37,000 --> 00:03:40,000
qui effectue une lecture incorrecte de la mémoire heap.

74
00:03:40,000 --> 00:03:49,000
Nous voyons aucune erreur ou alerte en compilation.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, le résumé des erreurs dit qu'il ya deux erreurs -

76
00:03:53,000 --> 00:03:56,000
deux lectures invalide de la taille 4 - octets, ce qui est.

77
00:03:56,000 --> 00:04:01,000
Les deux mauvais lit s'est produite dans la fonction principale de invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
le premier sur la ligne 16 et la seconde sur la ligne 19.

79
00:04:04,000 --> 00:04:06,000
Regardons le code.

80
00:04:06,000 --> 00:04:11,000
On dirait que le premier appel à printf essaie de lire un int après la fin de notre bloc de mémoire.

81
00:04:11,000 --> 00:04:13,000
Si nous regardons en arrière à la sortie Valgrind,

82
00:04:13,000 --> 00:04:16,000
nous voyons que Valgrind nous a dit exactement cela.

83
00:04:16,000 --> 00:04:19,000
L'adresse que nous essayons de lire commence 0 octets

84
00:04:19,000 --> 00:04:22,000
delà de l'extrémité du bloc de taille 16 octets -

85
00:04:22,000 --> 00:04:25,000
quatre compteurs 32 bits entiers que nous attribués.

86
00:04:25,000 --> 00:04:29,000
Autrement dit, l'adresse que nous essayions de lire commence juste à la fin de notre bloc,

87
00:04:29,000 --> 00:04:32,000
comme nous le voyons dans notre appel printf mauvais.

88
00:04:32,000 --> 00:04:36,000
Maintenant, invalide lectures peuvent sembler ne pas que les grandes d'un accord,

89
00:04:36,000 --> 00:04:39,000
mais si vous utilisez ces données pour contrôler le débit de votre programme -

90
00:04:39,000 --> 00:04:42,000
par exemple, dans le cadre d'une instruction if ou boucle -

91
00:04:42,000 --> 00:04:45,000
alors les choses peuvent aller mal en silence.

92
00:04:45,000 --> 00:04:47,000
Regardez comment je peux exécuter le programme invalid_read

93
00:04:47,000 --> 00:04:50,000
et rien hors de l'ordinaire qui se passe.

94
00:04:50,000 --> 00:04:52,000
Effrayant, hein?

95
00:04:52,000 --> 00:04:56,000
>> Maintenant, penchons-nous sur certains types plus d'erreurs que vous pouvez rencontrer dans votre code,

96
00:04:56,000 --> 00:04:59,000
et nous allons voir comment Valgrind les détecte.

97
00:04:59,000 --> 00:05:01,000
Nous venons de voir un exemple de invalid_read,

98
00:05:01,000 --> 00:05:04,000
alors maintenant nous allons vérifier une invalid_write.

99
00:05:04,000 --> 00:05:09,000
Encore une fois, aucune erreur ou alerte en compilation.

100
00:05:09,000 --> 00:05:12,000
Bon, Valgrind dit qu'il ya deux erreurs dans ce programme -

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

102
00:05:15,000 --> 00:05:18,000
Voyons maintenant ce code.

103
00:05:18,000 --> 00:05:21,000
On dirait que nous avons une instance de la strlen classique plus un bug.

104
00:05:21,000 --> 00:05:24,000
Le code n'est pas malloc un octet supplémentaire de l'espace

105
00:05:24,000 --> 00:05:26,000
pour le caractère / 0,

106
00:05:26,000 --> 00:05:30,000
alors quand str copie est allé à écrire à ssubstrlen "CS50 rocks!"

107
00:05:30,000 --> 00:05:33,000
il a écrit 1 octet après la fin de notre bloc.

108
00:05:33,000 --> 00:05:36,000
Le invalid_read vient quand nous faisons notre appel à printf.

109
00:05:36,000 --> 00:05:40,000
Printf finit la lecture de mémoire invalide quand il lit le fichier / 0 caractère

110
00:05:40,000 --> 00:05:43,000
qu'il n'y paraît à la fin de cette chaîne E c'est l'impression.

111
00:05:43,000 --> 00:05:45,000
Mais rien de tout cela échappé Valgrind.

112
00:05:45,000 --> 00:05:48,000
On voit qu'il a attiré l'invalid_write dans le cadre de la copie str

113
00:05:48,000 --> 00:05:51,000
à la ligne 11 de la principale, et la invalid_read fait partie de printf.

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

115
00:05:54,000 --> 00:05:57,000
Encore une fois, cela ne semble pas être un gros problème.

116
00:05:57,000 --> 00:06:00,000
Nous pouvons exécuter ce programme à plusieurs reprises en dehors de Valgrind

117
00:06:00,000 --> 00:06:03,000
et ne pas voir les symptômes d'erreurs.

118
00:06:03,000 --> 00:06:06,000
>> Toutefois, penchons-nous sur une légère variation de ce voir

119
00:06:06,000 --> 00:06:09,000
comment les choses peuvent devenir vraiment mauvais.

120
00:06:09,000 --> 00:06:14,000
Alors, d'accord, nous abusent des choses plus que juste un peu dans ce code.

121
00:06:14,000 --> 00:06:17,000
Nous ne sommes qu'à l'allocation d'espace sur le tas pour les deux chaînes

122
00:06:17,000 --> 00:06:19,000
la longueur de roches CS50,

123
00:06:19,000 --> 00:06:22,000
cette fois, se souvenant de l'/ 0 caractère.

124
00:06:22,000 --> 00:06:25,000
Mais alors que nous jetons dans une chaîne de super-long dans le bloc de mémoire

125
00:06:25,000 --> 00:06:27,000
S qui pointe.

126
00:06:27,000 --> 00:06:30,000
Quel effet cela aura-t sur le bloc de mémoire qui pointe à T?

127
00:06:30,000 --> 00:06:34,000
Eh bien, si les points de T à mémoire qui est juste à côté de S,

128
00:06:34,000 --> 00:06:37,000
vient juste après,

129
00:06:37,000 --> 00:06:39,000
alors nous pourrions avoir écrit sur une partie de T.

130
00:06:39,000 --> 00:06:41,000
Nous allons exécuter ce code.

131
00:06:41,000 --> 00:06:43,000
Regardez ce qui s'est passé.

132
00:06:43,000 --> 00:06:47,000
Les chaînes dont nous avons stockés dans nos blocs de tas deux semblaient avoir imprimé correctement.

133
00:06:47,000 --> 00:06:49,000
Rien ne semble pas mauvaise du tout.

134
00:06:49,000 --> 00:06:52,000
Cependant, revenons à notre code et

135
00:06:52,000 --> 00:06:55,000
commentez la ligne où nous copier CS50 roches

136
00:06:55,000 --> 00:06:59,000
dans le second bloc de mémoire, désigné par t.

137
00:06:59,000 --> 00:07:02,000
Maintenant, quand nous exécuter ce code nous devrions

138
00:07:02,000 --> 00:07:06,000
uniquement le contenu du premier bloc de mémoire imprimer.

139
00:07:06,000 --> 00:07:09,000
Whoa, même si nous n'avons pas str copie

140
00:07:09,000 --> 00:07:12,000
tous les caractères dans le bloc de tas second, celui pointé par T,

141
00:07:12,000 --> 00:07:15,000
nous obtenons une impression.

142
00:07:15,000 --> 00:07:18,000
En effet, la chaîne nous en peluche dans notre premier bloc

143
00:07:18,000 --> 00:07:21,000
est sorti le premier bloc et dans le second bloc,

144
00:07:21,000 --> 00:07:23,000
faisant tout semble normal.

145
00:07:23,000 --> 00:07:26,000
Valgrind, cependant, nous raconte l'histoire vraie.

146
00:07:26,000 --> 00:07:28,000
Nous y voilà.

147
00:07:28,000 --> 00:07:32,000
Toutes les personnes invalides lectures et écritures.

148
00:07:32,000 --> 00:07:36,000
>> Regardons un exemple d'un autre genre d'erreur.

149
00:07:36,000 --> 00:07:39,000
Ici, nous faisons quelque chose de regrettable.

150
00:07:39,000 --> 00:07:41,000
Nous saisissons l'espace pour un int sur le tas,

151
00:07:41,000 --> 00:07:45,000
et on initialise un pointeur int - p - pour pointer vers cet espace.

152
00:07:45,000 --> 00:07:48,000
Cependant, alors que notre pointeur est initialisé,

153
00:07:48,000 --> 00:07:52,000
les données qu'il a pointant vers ce que vient d'ordure est dans cette partie du tas.

154
00:07:52,000 --> 00:07:55,000
Ainsi, lorsque nous chargeons ces données en int i,

155
00:07:55,000 --> 00:07:57,000
Nous techniquement initialiser i,

156
00:07:57,000 --> 00:08:00,000
mais nous le faisons avec les données indésirables.

157
00:08:00,000 --> 00:08:03,000
L'appel à faire valoir, ce qui est une macro débogage à portée de main

158
00:08:03,000 --> 00:08:06,000
défini dans le bien nommé affirmer bibliothèque,

159
00:08:06,000 --> 00:08:09,000
annulerait le programme si son état test échoue.

160
00:08:09,000 --> 00:08:11,000
Autrement dit, si i n'est pas 0.

161
00:08:11,000 --> 00:08:14,000
Selon ce qui était dans le segment de mémoire, pointée par p,

162
00:08:14,000 --> 00:08:18,000
ce programme pourrait fonctionner parfois et ne parviennent pas à d'autres moments.

163
00:08:18,000 --> 00:08:20,000
Si cela fonctionne, nous ne faisons que de la chance.

164
00:08:20,000 --> 00:08:24,000
Le compilateur ne sera pas attraper cette erreur, mais Valgrind volonté certaine.

165
00:08:24,000 --> 00:08:28,000
Là, nous voyons l'erreur découlant de notre utilisation de ces données inutiles.

166
00:08:28,000 --> 00:08:32,000
>> Lorsque vous allouer de la mémoire heap mais ne le libérer ou de le libérer,

167
00:08:32,000 --> 00:08:34,000
que l'on appelle une fuite.

168
00:08:34,000 --> 00:08:37,000
Pour une petite éphémère programme qui tourne et quitte immédiatement,

169
00:08:37,000 --> 00:08:39,000
fuites sont relativement inoffensifs,

170
00:08:39,000 --> 00:08:42,000
mais pour un projet de plus grande taille et / ou la longévité,

171
00:08:42,000 --> 00:08:46,000
même une petite fuite peut aggraver en quelque chose de majeur.

172
00:08:46,000 --> 00:08:49,000
Pour CS50, nous nous attendons à ce que vous

173
00:08:49,000 --> 00:08:51,000
prendre soin de libérer toute la mémoire que vous allouez tas,

174
00:08:51,000 --> 00:08:54,000
puisque nous voulons vous de construire les compétences nécessaires pour gérer correctement le processus manuel

175
00:08:54,000 --> 00:08:56,000
requis par C.

176
00:08:56,000 --> 00:08:59,000
Pour ce faire, votre programme devrait avoir une exacte

177
00:08:59,000 --> 00:09:03,000
one-to-one correspondance entre malloc et des appels gratuits.

178
00:09:03,000 --> 00:09:06,000
Heureusement, Valgrind peut vous aider avec des fuites de mémoire aussi.

179
00:09:06,000 --> 00:09:09,000
Voici un programme qui fuit appelé fuite.C qui alloue

180
00:09:09,000 --> 00:09:13,000
l'espace sur le tas, écrit à elle, mais ne la libérer.

181
00:09:13,000 --> 00:09:16,000
On le compile avec Make et l'exécuter sous Valgrind,

182
00:09:16,000 --> 00:09:18,000
et nous voyons que, même si nous avons des erreurs de mémoire pas,

183
00:09:18,000 --> 00:09:20,000
nous avons une fuite.

184
00:09:20,000 --> 00:09:23,000
Il ya 16 octets définitivement perdus,

185
00:09:23,000 --> 00:09:27,000
ce qui signifie que le pointeur vers la mémoire n'était pas dans la portée lorsque le programme quitte.

186
00:09:27,000 --> 00:09:30,000
Maintenant, Valgrind ne nous donne pas une tonne d'informations à propos de la fuite,

187
00:09:30,000 --> 00:09:35,000
mais si nous suivons cette petite note qui lui donne vers le fond de son rapport

188
00:09:35,000 --> 00:09:38,000
relancer avec - Fuite-check = plein

189
00:09:38,000 --> 00:09:41,000
pour voir tous les détails de fuite de mémoire,

190
00:09:41,000 --> 00:09:44,000
nous aurons plus d'informations.

191
00:09:44,000 --> 00:09:46,000
Maintenant, dans le résumé tas,

192
00:09:46,000 --> 00:09:50,000
Valgrind nous dit où la mémoire qui a été perdu a été initialement alloué.

193
00:09:50,000 --> 00:09:52,000
Tout comme nous savons de la recherche dans le code source,

194
00:09:52,000 --> 00:09:55,000
Valgrind nous informe que nous avons fui la mémoire

195
00:09:55,000 --> 00:09:58,000
allouée par un appel à malloc à la ligne 8 de fuite.C

196
00:09:58,000 --> 00:10:00,000
dans la fonction principale.

197
00:10:00,000 --> 00:10:02,000
Très chouette.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind catégorise les fuites en utilisant ces termes:

199
00:10:04,000 --> 00:10:07,000
Définitivement perdu - c'est segment de mémoire allouée

200
00:10:07,000 --> 00:10:10,000
dans laquelle le programme n'a plus un pointeur.

201
00:10:10,000 --> 00:10:14,000
Valgrind sait que vous aviez autrefois le pointeur, mais ont depuis perdu la trace de celui-ci.

202
00:10:14,000 --> 00:10:17,000
Cette mémoire est certainement une fuite.

203
00:10:17,000 --> 00:10:20,000
Indirectement perdu - c'est segment de mémoire allouée

204
00:10:20,000 --> 00:10:24,000
à laquelle les seuls pointeurs à elle aussi est perdu.

205
00:10:24,000 --> 00:10:27,000
Par exemple, si vous avez perdu votre pointeur sur le premier nœud d'une liste chaînée,

206
00:10:27,000 --> 00:10:30,000
puis le premier nœud lui-même serait définitivement perdu,

207
00:10:30,000 --> 00:10:34,000
tandis que tous les nœuds seraient indirectement perdu.

208
00:10:34,000 --> 00:10:37,000
Peut-être perdu - c'est segment de mémoire allouée

209
00:10:37,000 --> 00:10:41,000
dans laquelle Valgrind ne peut pas être sûr de savoir s'il existe un pointeur ou non.

210
00:10:41,000 --> 00:10:44,000
Est toujours joignable segment de mémoire allouée

211
00:10:44,000 --> 00:10:47,000
dans laquelle le programme a encore un pointeur à la sortie,

212
00:10:47,000 --> 00:10:50,000
ce qui signifie généralement que quelques points de variables globales à elle.

213
00:10:50,000 --> 00:10:53,000
Pour vérifier ces fuites, vous aurez également à inclure l'option

214
00:10:53,000 --> 00:10:55,000
- Encore accessible = oui

215
00:10:55,000 --> 00:10:58,000
dans votre invocation de Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Ces différents cas peuvent nécessiter des stratégies différentes pour les nettoyer,

217
00:11:01,000 --> 00:11:05,000
mais les fuites doivent être éliminées.

218
00:11:05,000 --> 00:11:08,000
Malheureusement, la réparation des fuites peut être difficile à faire,

219
00:11:08,000 --> 00:11:11,000
puisque les appels erronés à la libre peut faire exploser votre programme.

220
00:11:11,000 --> 00:11:14,000
Par exemple, si nous regardons invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
nous voyons un exemple de libération de la mémoire mauvais.

222
00:11:18,000 --> 00:11:21,000
Quel devrait être un simple appel à libérer la totalité du bloc

223
00:11:21,000 --> 00:11:24,000
de la mémoire pointée par int_block,

224
00:11:24,000 --> 00:11:27,000
est plutôt devenu une tentative pour libérer chaque section int entreprises

225
00:11:27,000 --> 00:11:29,000
de la mémoire individuellement.

226
00:11:29,000 --> 00:11:32,000
Ce sera une rupture catastrophique.

227
00:11:32,000 --> 00:11:34,000
Boom! Qu'est-ce une erreur.

228
00:11:34,000 --> 00:11:36,000
Ce n'est certainement pas bon.

229
00:11:36,000 --> 00:11:39,000
Si vous êtes coincé avec ce genre d'erreur, cependant, et vous ne savez pas où chercher,

230
00:11:39,000 --> 00:11:41,000
se replier sur votre nouveau meilleur ami.

231
00:11:41,000 --> 00:11:44,000
Vous l'avez deviné - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, comme toujours, sait exactement ce qui se passe.

233
00:11:47,000 --> 00:11:50,000
Les chiffres alloc et libre ne correspondent pas.

234
00:11:50,000 --> 00:11:52,000
Nous avons obtenu 1 alloc et 4 libère.

235
00:11:52,000 --> 00:11:55,000
Et Valgrind nous dit aussi où le premier appel mauvais gratuit -

236
00:11:55,000 --> 00:11:58,000
l'une qui a déclenché la blowup - vient -

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

238
00:12:00,000 --> 00:12:03,000
Comme vous le voyez, les appels mauvaises pour libérer sont vraiment mauvais,

239
00:12:03,000 --> 00:12:05,000
nous vous recommandons de laisser votre fuite programme

240
00:12:05,000 --> 00:12:08,000
pendant que vous travaillez sur l'obtention de la fonctionnalité correcte.

241
00:12:08,000 --> 00:12:12,000
Commencer à chercher des fuites seulement après que votre programme fonctionne correctement,

242
00:12:12,000 --> 00:12:14,000
sans autres erreurs.

243
00:12:14,000 --> 00:12:16,000
>> Et c'est tout ce que nous avons pour cette vidéo.

244
00:12:16,000 --> 00:12:18,000
Maintenant, qu'est-ce que tu attends?

245
00:12:18,000 --> 00:12:21,000
Aller courir Valgrind sur vos programmes en ce moment.

246
00:12:21,000 --> 00:12:25,000
Mon nom est Nate Hardison. C'est CS50. [CS50.TV]