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

4
00:00:07,000 --> 00:00:10,000
Algunos de los errores más difíciles en los programas en C

5
00:00:10,000 --> 00:00:13,000
provienen de la mala gestión de la memoria.

6
00:00:13,000 --> 00:00:15,000
Hay un gran número de formas de enredar las cosas,

7
00:00:15,000 --> 00:00:17,000
incluyendo la asignación de la cantidad incorrecta de la memoria,

8
00:00:17,000 --> 00:00:20,000
olvidar inicializar variables,

9
00:00:20,000 --> 00:00:23,000
escrito antes o después del final de un tampón,

10
00:00:23,000 --> 00:00:25,000
y la liberación de mantener los tiempos de memoria múltiples.

11
00:00:25,000 --> 00:00:28,000
Los síntomas van desde fallos intermitentes

12
00:00:28,000 --> 00:00:30,000
a los valores misteriosamente sobrescritos,

13
00:00:30,000 --> 00:00:34,000
a menudo en lugares y tiempos muy alejados del error original.

14
00:00:34,000 --> 00:00:37,000
Rastreando el problema observado de nuevo a la causa subyacente

15
00:00:37,000 --> 00:00:39,000
puede ser un reto,

16
00:00:39,000 --> 00:00:42,000
pero, afortunadamente, hay un programa llamado útil Valgrind

17
00:00:42,000 --> 00:00:44,000
que se puede hacer mucho para ayudar.

18
00:00:44,000 --> 00:00:47,000
>> Ejecutar un programa bajo Valgrind para que

19
00:00:47,000 --> 00:00:50,000
comprobación extensa de asignaciones de memoria heap y accesos.

20
00:00:50,000 --> 00:00:53,000
Cuando Valgrind detecta un problema, se le da inmediata,

21
00:00:53,000 --> 00:00:56,000
información directa que le permite

22
00:00:56,000 --> 00:00:58,000
más fácilmente encontrar y solucionar el problema.

23
00:00:58,000 --> 00:01:01,000
Valgrind también informes sobre problemas de memoria menos mortales,

24
00:01:01,000 --> 00:01:04,000
tales como pérdidas de memoria, asignación de memoria heap,

25
00:01:04,000 --> 00:01:07,000
y olvidarse de liberarlo.

26
00:01:07,000 --> 00:01:10,000
Como nuestro compilador, Clang, en nuestro depurador GDB,

27
00:01:10,000 --> 00:01:14,000
Valgrind es software libre, y se instala en el aparato.

28
00:01:14,000 --> 00:01:16,000
Valgrind se ejecuta en el ejecutable binario,

29
00:01:16,000 --> 00:01:20,000
no tu. co. archivos de origen h de código,

30
00:01:20,000 --> 00:01:23,000
así que asegúrese de que usted haya compilado una copia actualizada al día de su programa

31
00:01:23,000 --> 00:01:25,000
utilizando Clang o hacer.

32
00:01:25,000 --> 00:01:28,000
A continuación, ejecuta el programa bajo Valgrind puede ser

33
00:01:28,000 --> 00:01:32,000
tan simple como prefijo el símbolo del programa estándar con el Valgrind palabra,

34
00:01:32,000 --> 00:01:35,000
que se inicia Valgrind y ejecuta el programa en el interior de la misma.

35
00:01:35,000 --> 00:01:38,000
Al iniciar, Valgrind hace algún complejo

36
00:01:38,000 --> 00:01:41,000
jiggering para configurar el ejecutable de la vigilancia a la memoria,

37
00:01:41,000 --> 00:01:44,000
por lo que puede tardar un poco para ponerse en marcha.

38
00:01:44,000 --> 00:01:48,000
Entonces, el programa se ejecutará normalmente, pueden ser mucho más lentamente,

39
00:01:48,000 --> 00:01:52,000
y cuando termina, Valgrind imprimirá un resumen de su uso de memoria.

40
00:01:52,000 --> 00:01:58,000
Si todo va bien, se verá algo como esto:

41
00:01:58,000 --> 00:02:01,000
En este caso,. / Clean_program

42
00:02:01,000 --> 00:02:04,000
es la ruta de acceso al programa que desea ejecutar.

43
00:02:04,000 --> 00:02:06,000
Y mientras esto no se toma ningún argumento,

44
00:02:06,000 --> 00:02:09,000
si lo hiciera yo acababa de ellos rumbo a la final de la orden como de costumbre.

45
00:02:09,000 --> 00:02:12,000
Programa Clean es un programa poco tonto que he creado

46
00:02:12,000 --> 00:02:15,000
que asigna espacio para un bloque de enteros en el montón,

47
00:02:15,000 --> 00:02:19,000
poner algunos valores dentro de ellos, y libera toda la manzana.

48
00:02:19,000 --> 00:02:23,000
Esto es lo que usted está tirando para, sin errores y sin fugas.

49
00:02:23,000 --> 00:02:27,000
>> Otra métrica importante es el número total de bytes asignados.

50
00:02:27,000 --> 00:02:32,000
Dependiendo del programa, si sus asignaciones están en megabytes o más,

51
00:02:32,000 --> 00:02:34,000
usted está probablemente haciendo algo mal.

52
00:02:34,000 --> 00:02:37,000
¿Estás innecesariamente almacenar duplicados?

53
00:02:37,000 --> 00:02:40,000
¿Está utilizando la pila de almacenamiento, cuando sería mejor usar la pila?

54
00:02:40,000 --> 00:02:43,000
Por lo tanto, los errores de memoria pueden ser verdaderamente mal.

55
00:02:43,000 --> 00:02:46,000
Los más evidentes causar accidentes espectaculares,

56
00:02:46,000 --> 00:02:49,000
pero aun así, todavía puede ser difícil de identificar

57
00:02:49,000 --> 00:02:51,000
exactamente lo que condujo a la caída.

58
00:02:51,000 --> 00:02:54,000
Peor aún, un programa con un error de memoria

59
00:02:54,000 --> 00:02:56,000
todavía puede compilar limpiamente

60
00:02:56,000 --> 00:02:58,000
y todavía puede parecen funcionar correctamente

61
00:02:58,000 --> 00:03:01,000
porque se las arregló para tener suerte la mayor parte del tiempo.

62
00:03:01,000 --> 00:03:04,000
Después de varios "resultados exitosos"

63
00:03:04,000 --> 00:03:07,000
usted podría pensar que un accidente es un golpe de suerte de la computadora,

64
00:03:07,000 --> 00:03:10,000
pero el equipo nunca se equivoca.

65
00:03:10,000 --> 00:03:13,000
>> Ejecución de Valgrind puede ayudarle a localizar la causa de los errores de memoria visibles

66
00:03:13,000 --> 00:03:18,000
así como encontrar al acecho errores que ni siquiera aún conocemos.

67
00:03:18,000 --> 00:03:22,000
Cada vez Valgrind detecta un problema, se muestra información acerca de lo que observa.

68
00:03:22,000 --> 00:03:24,000
Cada artículo es bastante escueto -

69
00:03:24,000 --> 00:03:27,000
la línea de la fuente de la instrucción infractora, cuál es el problema,

70
00:03:27,000 --> 00:03:30,000
y un poco de información acerca de la memoria involucrados -

71
00:03:30,000 --> 00:03:34,000
pero a menudo es suficiente información para dirigir su atención hacia el lugar correcto.

72
00:03:34,000 --> 00:03:37,000
Aquí está un ejemplo de Valgrind ejecuta en un programa defectuoso

73
00:03:37,000 --> 00:03:40,000
que hace una lectura válida de la memoria heap.

74
00:03:40,000 --> 00:03:49,000
No vemos los errores o advertencias de compilación.

75
00:03:49,000 --> 00:03:53,000
Uh-oh, el resumen error dice que hay dos errores -

76
00:03:53,000 --> 00:03:56,000
dos lecturas inválidas de tamaño 4 - bytes, es decir.

77
00:03:56,000 --> 00:04:01,000
Tanto mala lee producido en la función principal de invalid_read.c,

78
00:04:01,000 --> 00:04:04,000
el primero en la línea 16 y la segunda en la línea 19.

79
00:04:04,000 --> 00:04:06,000
Veamos el código.

80
00:04:06,000 --> 00:04:11,000
Parece que la primera llamada a printf intenta leer un int allá del final de nuestro bloque de memoria.

81
00:04:11,000 --> 00:04:13,000
Si miramos hacia atrás en la salida de Valgrind,

82
00:04:13,000 --> 00:04:16,000
vemos que Valgrind nos dijo exactamente eso.

83
00:04:16,000 --> 00:04:19,000
La dirección que estamos tratando de leer empieza 0 bytes

84
00:04:19,000 --> 00:04:22,000
más allá del extremo del bloque de tamaño 16 bytes -

85
00:04:22,000 --> 00:04:25,000
cuatro enteros de 32-bit que nos asignan.

86
00:04:25,000 --> 00:04:29,000
Es decir, la dirección que estábamos tratando de leer empieza justo al final de nuestro bloque,

87
00:04:29,000 --> 00:04:32,000
tal como vemos en nuestra llamada printf malo.

88
00:04:32,000 --> 00:04:36,000
Ahora, no es válido lecturas no parece ser tan grande de un acuerdo,

89
00:04:36,000 --> 00:04:39,000
pero si usted está utilizando esos datos para controlar el flujo del programa -

90
00:04:39,000 --> 00:04:42,000
por ejemplo, como parte de una sentencia if o loop -

91
00:04:42,000 --> 00:04:45,000
entonces las cosas pueden ir mal en silencio.

92
00:04:45,000 --> 00:04:47,000
Mira cómo puedo ejecutar el programa invalid_read

93
00:04:47,000 --> 00:04:50,000
y nada fuera de lo común sucede.

94
00:04:50,000 --> 00:04:52,000
Da miedo, ¿eh?

95
00:04:52,000 --> 00:04:56,000
>> Ahora, echemos un vistazo a algunos tipos más de los errores que pueden surgir en el código,

96
00:04:56,000 --> 00:04:59,000
y vamos a ver cómo Valgrind los detecta.

97
00:04:59,000 --> 00:05:01,000
Acabamos de ver un ejemplo de un invalid_read,

98
00:05:01,000 --> 00:05:04,000
por lo que ahora vamos a ver un invalid_write.

99
00:05:04,000 --> 00:05:09,000
Una vez más, no hay errores o advertencias de compilación.

100
00:05:09,000 --> 00:05:12,000
Bueno, Valgrind dice que hay dos errores en este programa -

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

102
00:05:15,000 --> 00:05:18,000
Vamos a ver este código.

103
00:05:18,000 --> 00:05:21,000
Parece que tenemos un ejemplo del clásico strlen además de un bug.

104
00:05:21,000 --> 00:05:24,000
El código no malloc un byte extra de espacio

105
00:05:24,000 --> 00:05:26,000
por el carácter / 0,

106
00:05:26,000 --> 00:05:30,000
así que cuando str copia fue a escribir en ssubstrlen "CS50 rocks!"

107
00:05:30,000 --> 00:05:33,000
lo escribió un byte más allá del final de nuestro bloque.

108
00:05:33,000 --> 00:05:36,000
El invalid_read viene cuando hacemos nuestra llamada a printf.

109
00:05:36,000 --> 00:05:40,000
Printf termina la lectura de memoria no válida cuando se lee la / 0 carácter

110
00:05:40,000 --> 00:05:43,000
como se ve en el extremo de esta cadena E es impresión.

111
00:05:43,000 --> 00:05:45,000
Pero nada de esto escapó Valgrind.

112
00:05:45,000 --> 00:05:48,000
Vemos que llamó la invalid_write como parte de la copia de str

113
00:05:48,000 --> 00:05:51,000
en la línea 11 de la principal, y la invalid_read es parte de printf.

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

115
00:05:54,000 --> 00:05:57,000
De nuevo, esto no parece ser un gran problema.

116
00:05:57,000 --> 00:06:00,000
Podemos ejecutar este programa una y otra vez fuera de Valgrind

117
00:06:00,000 --> 00:06:03,000
y no ve ningún síntoma de error.

118
00:06:03,000 --> 00:06:06,000
>> Sin embargo, vamos a ver una ligera variación de esto para ver

119
00:06:06,000 --> 00:06:09,000
cómo las cosas pueden ponerse muy mal.

120
00:06:09,000 --> 00:06:14,000
Así que, es cierto, estamos abusando de cosas más que sólo un poco en este código.

121
00:06:14,000 --> 00:06:17,000
Sólo estamos asignando espacio en el montón de dos cadenas

122
00:06:17,000 --> 00:06:19,000
la longitud de CS50 rocas,

123
00:06:19,000 --> 00:06:22,000
esta vez, recordando la / 0 caracteres.

124
00:06:22,000 --> 00:06:25,000
Pero luego tirar de una cadena de super-larga en el bloque de memoria

125
00:06:25,000 --> 00:06:27,000
S que está apuntando.

126
00:06:27,000 --> 00:06:30,000
¿Qué efecto tendrá esto en el bloque de memoria que apunta a T?

127
00:06:30,000 --> 00:06:34,000
Bueno, si los puntos de T a la memoria que hay justo al lado de S,

128
00:06:34,000 --> 00:06:37,000
viene justo después de ella,

129
00:06:37,000 --> 00:06:39,000
entonces podríamos haber escrito sobre parte de T.

130
00:06:39,000 --> 00:06:41,000
Vamos a ejecutar este código.

131
00:06:41,000 --> 00:06:43,000
Mira lo que pasó.

132
00:06:43,000 --> 00:06:47,000
Las cadenas se almacenan en nuestros bloques montón ambos parecían haber impreso correctamente.

133
00:06:47,000 --> 00:06:49,000
Nada parece mal en absoluto.

134
00:06:49,000 --> 00:06:52,000
Sin embargo, volvamos a nuestro código y

135
00:06:52,000 --> 00:06:55,000
comentar la línea donde copiamos CS50 rocas

136
00:06:55,000 --> 00:06:59,000
en el segundo bloque de memoria, a la que apunta t.

137
00:06:59,000 --> 00:07:02,000
Ahora, cuando ejecute este código debemos

138
00:07:02,000 --> 00:07:06,000
sólo ver el contenido del primer bloque de memoria imprimir.

139
00:07:06,000 --> 00:07:09,000
Whoa, aunque nosotros no lo hicimos str copia

140
00:07:09,000 --> 00:07:12,000
los caracteres en el bloque montón segundo, el apuntado por T,

141
00:07:12,000 --> 00:07:15,000
obtenemos una impresión.

142
00:07:15,000 --> 00:07:18,000
De hecho, la cadena se metió en nuestro primer bloque

143
00:07:18,000 --> 00:07:21,000
invadieron el bloque primero y en el segundo bloque,

144
00:07:21,000 --> 00:07:23,000
haciendo que todo parezca normal.

145
00:07:23,000 --> 00:07:26,000
Valgrind, sin embargo, nos cuenta la historia real.

146
00:07:26,000 --> 00:07:28,000
Ahí vamos.

147
00:07:28,000 --> 00:07:32,000
Todos aquellos inválido lee y escribe.

148
00:07:32,000 --> 00:07:36,000
>> Veamos un ejemplo de otro tipo de error.

149
00:07:36,000 --> 00:07:39,000
Aquí hacemos algo bastante lamentable.

150
00:07:39,000 --> 00:07:41,000
Cogemos el espacio para un entero en el heap,

151
00:07:41,000 --> 00:07:45,000
y nos inicializar un puntero int - p - para apuntar a ese espacio.

152
00:07:45,000 --> 00:07:48,000
Sin embargo, mientras que nuestro puntero se inicializa,

153
00:07:48,000 --> 00:07:52,000
los datos que se está apuntando a sólo lo ha basura está en esa parte de la pila.

154
00:07:52,000 --> 00:07:55,000
Así que cuando cargamos esos datos en int i,

155
00:07:55,000 --> 00:07:57,000
que técnicamente i inicializar,

156
00:07:57,000 --> 00:08:00,000
pero lo hacemos con datos de la chatarra.

157
00:08:00,000 --> 00:08:03,000
La llamada a afirmar, que es una macro de depuración práctico

158
00:08:03,000 --> 00:08:06,000
se define en el bien llamado afirmar biblioteca,

159
00:08:06,000 --> 00:08:09,000
abortará el programa si su condición de prueba falla.

160
00:08:09,000 --> 00:08:11,000
Es decir, si no es 0.

161
00:08:11,000 --> 00:08:14,000
Dependiendo de lo que había en el espacio del montón, apuntado por p,

162
00:08:14,000 --> 00:08:18,000
este programa puede trabajar a veces y no en otros momentos.

163
00:08:18,000 --> 00:08:20,000
Si funciona, sólo estamos teniendo suerte.

164
00:08:20,000 --> 00:08:24,000
El compilador no detectará este error, pero Valgrind voluntad segura.

165
00:08:24,000 --> 00:08:28,000
Allí vemos que el error resultante de nuestro uso de esos datos no deseados.

166
00:08:28,000 --> 00:08:32,000
>> Al asignar memoria del montón, pero no lo desasignar o liberarlo,

167
00:08:32,000 --> 00:08:34,000
que se llama una fuga.

168
00:08:34,000 --> 00:08:37,000
Para un pequeño, efímero programa que se ejecuta y sale inmediatamente,

169
00:08:37,000 --> 00:08:39,000
fugas son bastante inofensivos,

170
00:08:39,000 --> 00:08:42,000
pero para un proyecto de mayor tamaño y / o la longevidad,

171
00:08:42,000 --> 00:08:46,000
incluso una pequeña fuga puede complicar en algo importante.

172
00:08:46,000 --> 00:08:49,000
Para CS50, esperamos que

173
00:08:49,000 --> 00:08:51,000
cuidar de liberar toda la memoria heap que asigne,

174
00:08:51,000 --> 00:08:54,000
ya que queremos que usted construya los conocimientos necesarios para manejar adecuadamente el proceso manual

175
00:08:54,000 --> 00:08:56,000
requerido por C.

176
00:08:56,000 --> 00:08:59,000
Para ello, el programa debe tener un exacto

177
00:08:59,000 --> 00:09:03,000
uno-a-uno correspondencia entre malloc y llamadas gratuitas.

178
00:09:03,000 --> 00:09:06,000
Afortunadamente, Valgrind puede ayudar con las pérdidas de memoria también.

179
00:09:06,000 --> 00:09:09,000
Aquí hay un programa llamado fugas leak.c que asigna

180
00:09:09,000 --> 00:09:13,000
espacio en el montón, escribe en él, pero no lo liberará.

181
00:09:13,000 --> 00:09:16,000
Nos compilarlo con make y ejecutar el programa bajo Valgrind,

182
00:09:16,000 --> 00:09:18,000
y vemos que, si bien no tenemos errores de memoria,

183
00:09:18,000 --> 00:09:20,000
tenemos una fuga.

184
00:09:20,000 --> 00:09:23,000
Hay 16 bytes definitivamente perdidos,

185
00:09:23,000 --> 00:09:27,000
lo que significa que el puntero a la memoria que no estaba en el ámbito cuando el programa se cierra.

186
00:09:27,000 --> 00:09:30,000
Ahora, Valgrind no nos da un montón de información acerca de la fuga,

187
00:09:30,000 --> 00:09:35,000
pero si seguimos esta pequeña nota que da hacia el fondo de su informe

188
00:09:35,000 --> 00:09:38,000
volver a ejecutar con - Fuga-check = completo

189
00:09:38,000 --> 00:09:41,000
para ver los detalles completos de memoria perdida,

190
00:09:41,000 --> 00:09:44,000
vamos a obtener más información.

191
00:09:44,000 --> 00:09:46,000
Ahora bien, en el resumen montón,

192
00:09:46,000 --> 00:09:50,000
Valgrind nos dice que la memoria que se perdió fue asignado inicialmente.

193
00:09:50,000 --> 00:09:52,000
Así como sabemos de mirar en el código fuente,

194
00:09:52,000 --> 00:09:55,000
Valgrind nos informa que filtró la memoria

195
00:09:55,000 --> 00:09:58,000
asignado con una llamada a malloc en la línea 8 de leak.c

196
00:09:58,000 --> 00:10:00,000
en la función principal.

197
00:10:00,000 --> 00:10:02,000
Bastante ingenioso.

198
00:10:02,000 --> 00:10:04,000
>> Valgrind clasifica fugas usando estos términos:

199
00:10:04,000 --> 00:10:07,000
Definitivamente perdido - esto es la pila de memoria asignada

200
00:10:07,000 --> 00:10:10,000
en que el programa ya no tiene un puntero.

201
00:10:10,000 --> 00:10:14,000
Valgrind sabe que una vez tuvo el puntero, pero desde entonces han perdido la pista.

202
00:10:14,000 --> 00:10:17,000
Esta memoria es, sin duda filtrado.

203
00:10:17,000 --> 00:10:20,000
Indirectamente perdido - esta es la pila de memoria asignada

204
00:10:20,000 --> 00:10:24,000
a la que sólo los punteros a que también se pierden.

205
00:10:24,000 --> 00:10:27,000
Por ejemplo, si usted perdió su puntero al primer nodo de una lista enlazada,

206
00:10:27,000 --> 00:10:30,000
entonces el primer nodo en sí sería definitivamente perdido,

207
00:10:30,000 --> 00:10:34,000
mientras que los nodos subsiguientes serían indirectamente perdido.

208
00:10:34,000 --> 00:10:37,000
Posiblemente perdido - esta es la pila de memoria asignada

209
00:10:37,000 --> 00:10:41,000
a la que Valgrind no puede estar seguro si hay un puntero o no.

210
00:10:41,000 --> 00:10:44,000
Todavía es accesible la pila de memoria asignada

211
00:10:44,000 --> 00:10:47,000
en que el programa todavía tiene un puntero en la salida,

212
00:10:47,000 --> 00:10:50,000
que significa típicamente que apunta una variable global a la misma.

213
00:10:50,000 --> 00:10:53,000
Para comprobar si estas filtraciones, usted también tendrá que incluir la opción

214
00:10:53,000 --> 00:10:55,000
- Aún alcanzable = yes

215
00:10:55,000 --> 00:10:58,000
en su advocación de Valgrind.

216
00:10:58,000 --> 00:11:01,000
>> Estos casos pueden requerir diferentes estrategias diferentes para limpiarlas,

217
00:11:01,000 --> 00:11:05,000
pero las fugas deben ser eliminados.

218
00:11:05,000 --> 00:11:08,000
Por desgracia, la fijación de las fugas pueden ser difícil de hacer,

219
00:11:08,000 --> 00:11:11,000
ya que las llamadas incorrectas a libre puede explotar su programa.

220
00:11:11,000 --> 00:11:14,000
Por ejemplo, si nos fijamos en invalid_free.c,

221
00:11:14,000 --> 00:11:18,000
vemos un ejemplo de desasignación mal recuerdo.

222
00:11:18,000 --> 00:11:21,000
Lo que debería ser una sola llamada a liberar a todo el bloque

223
00:11:21,000 --> 00:11:24,000
de memoria apuntada por int_block,

224
00:11:24,000 --> 00:11:27,000
en cambio, ha convertido en un intento por liberar a cada sección del tamaño de int

225
00:11:27,000 --> 00:11:29,000
de la memoria individualmente.

226
00:11:29,000 --> 00:11:32,000
Esto fallará catastróficamente.

227
00:11:32,000 --> 00:11:34,000
Boom! ¡Qué error.

228
00:11:34,000 --> 00:11:36,000
Esto definitivamente no es bueno.

229
00:11:36,000 --> 00:11:39,000
Si usted está atascado con este tipo de error, sin embargo, y usted no sabe dónde buscar,

230
00:11:39,000 --> 00:11:41,000
recurrir a su nuevo mejor amigo.

231
00:11:41,000 --> 00:11:44,000
Usted lo adivinó - Valgrind.

232
00:11:44,000 --> 00:11:47,000
Valgrind, como siempre, sabe exactamente lo que pasa.

233
00:11:47,000 --> 00:11:50,000
Los recuentos alloc y libre no coinciden.

234
00:11:50,000 --> 00:11:52,000
Tenemos un alloc y 4 libra.

235
00:11:52,000 --> 00:11:55,000
Y Valgrind también nos dice que la primera llamada gratuita malo -

236
00:11:55,000 --> 00:11:58,000
la que desencadenó la explosión - se viene -

237
00:11:58,000 --> 00:12:00,000
la línea 16.

238
00:12:00,000 --> 00:12:03,000
Como puede ver, las llamadas malas para liberar son realmente malas,

239
00:12:03,000 --> 00:12:05,000
lo que se recomienda dejar que su fuga programa

240
00:12:05,000 --> 00:12:08,000
mientras que usted está trabajando en conseguir el correcto funcionamiento.

241
00:12:08,000 --> 00:12:12,000
Comience a buscar fugas sólo después de que su programa está funcionando correctamente,

242
00:12:12,000 --> 00:12:14,000
sin otros errores.

243
00:12:14,000 --> 00:12:16,000
>> Y eso es todo lo que tenemos para este video.

244
00:12:16,000 --> 00:12:18,000
Ahora, ¿qué estás esperando?

245
00:12:18,000 --> 00:12:21,000
Ir ejecutar Valgrind en sus programas en estos momentos.

246
00:12:21,000 --> 00:12:25,000
Mi nombre es Nate Hardison. Esto es CS50. [CS50.TV]