0
268
VisualizaçõesC - ¿Valgrind en Mac muestra un resultado diferente al de Linux?
Aquí hay un programa muy simple que escribí para mostrar las diferencias entre las salidas de valgrind en Mac (El Capitan) y Linux Mint 17.2.
¿Hay alguna forma de obtener el mismo tipo de salida en Mac? No entiendo por qué muestra más uso de almacenamiento dinámico en Mac que en Linux.
Por una extraña razón , Linux Mint muestra que se está liberando la memoria , mientras que OSX no
#include <stdio.h> #include <string.h> #include <stdlib.h> int main(int argc, char const *argv[]) { char *str = (char *)malloc(15); strcpy(str, "Hello World!"); printf("%s\n", str); free(str); return 0; } Linux Mint 17.2 
Mac OSX El Capitán 
2 Respostas
Responde à pergunta0
La biblioteca estándar de C y el tiempo de ejecución hacen cosas antes de que se llame a main , y printf también hace cosas internamente. Estas "cosas" pueden incluir asignaciones de memoria. Esto es específico de la implementación, por lo que no sorprende que implementaciones completamente diferentes muestren diferentes cantidades de asignaciones.
Luego, cuando el programa finaliza, es posible que en realidad no sea necesario free ninguna asignación de montón, porque cuando finaliza el proceso, el montón desaparecerá , poof, eliminado por el sistema operativo (en un sistema operativo de escritorio como los dos anteriores). El código de la aplicación debe liberar toda la memoria que asigna (debido a la portabilidad, y porque entonces puede usar herramientas como valgrind , y porque es "limpio"). Pero para la plataforma y el código de biblioteca específico del compilador, solo ralentizaría la salida de cada programa, sin ganancia. Entonces, la biblioteca que no lo hace es básicamente una optimización, que normalmente no debería hacer en su propio programa (a menos que realmente pueda medir que hace una diferencia en alguna parte).
Por lo tanto, las herramientas como valgrind generalmente contienen listas de supresión para bloques de memoria no liberados conocidos. También puede configurar sus propias listas de supresión para cualquier biblioteca que utilice y que no libere toda la memoria al salir del programa. Pero cuando trabaje con supresiones, asegúrese de suprimir casos seguros y no ocultar pérdidas de memoria reales.
Especulación: debido a que aquí la diferencia en el número de asignaciones es bastante grande, uno podría arriesgarse a adivinar que la implementación de Linux usa solo variables estáticas/globales, mientras que la implementación de Mac también usa asignaciones de montón. Y los datos reales almacenados allí pueden incluir cosas como búferes stdin/stdout/stderr. Ahora, esto es solo una suposición, no verifiqué el código fuente, pero el propósito es dar una idea de para qué se podrían necesitar las asignaciones.
0
Debe aprender a interpretar los resultados, especialmente en Mac OS X.
La salida de tu Mac dice (Ojalá no tuviera que escribir esto, ¡maldita sea, las imágenes de la pantalla son tan dolorosas!):
definitely lost: 0 bytes in 0 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks still reachable: 0 bytes in 0 blocks suppressed: 26,091 bytes in 184 blocksEso significa lo que dice: no tienes pérdidas de memoria. El material suprimido es del código de inicio de la biblioteca de tiempo de ejecución de Mac C. Asigna bastante espacio (la mayoría de 26 KiB en su máquina, con 184 asignaciones separadas) y no lo libera explícitamente antes de que se ejecute el programa. Es por eso que están suprimidos: no son una falla de su programa, y esencialmente no hay nada que pueda hacer al respecto. Esa es la forma de vida en Mac. FWIW, acabo de ejecutar un programa mío y obtuve:
==57081== ==57081== HEAP SUMMARY: ==57081== in use at exit: 38,858 bytes in 419 blocks ==57081== total heap usage: 550 allocs, 131 frees, 46,314 bytes allocated ==57081== ==57081== LEAK SUMMARY: ==57081== definitely lost: 0 bytes in 0 blocks ==57081== indirectly lost: 0 bytes in 0 blocks ==57081== possibly lost: 0 bytes in 0 blocks ==57081== still reachable: 0 bytes in 0 blocks ==57081== suppressed: 38,858 bytes in 419 blocks ==57081== ==57081== For counts of detected and suppressed errors, rerun with: -v ==57081== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)No sé por qué tengo 12 KiB más de espacio y 235 asignaciones más del sistema de tiempo de ejecución que usted. Sin embargo, este es absolutamente el comportamiento normal en Mac.
Si hay una actualización importante del o/s, las antiguas supresiones pueden dejar de ser efectivas, y de repente puede tener muchos más 'aún accesibles' u otros 'problemas' de memoria; en ese momento, examina los informes cuidadosamente y luego genera nuevas supresiones. Tengo un archivo con 84 supresiones que estaba usando en un momento, luego obtuve una nueva versión de Valgrind y ya estaban en su lugar.