MacOs de Valgrind y error Syscall param msg-> desc.port.name apunta a byte (s) sin inicializar

Intenté ejecutar valgrind 3.13 y 3.14 (en macOs 10.12.6) en un proyecto muy simple, pero obtuve un extraño error con el que nunca antes había entrado en mi Linux.

  1. Progtwig de c muy simple main.c :

     int main() { return (0); } 
  2. Recostackción con cc :

     $> cc main.c 
  3. Ejecutar mi progtwig simple con valgrind :

     $> valgrind ./a.out 
  4. Salida de valgrind:

     ==12768== Memcheck, a memory error detector ==12768== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==12768== Using Valgrind-3.14.0.SVN and LibVEX; rerun with -h for copyright info ==12768== Command: ./a.out ==12768== ==12768== Syscall param msg->desc.port.name points to uninitialised byte(s) ==12768== at 0x10049434A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib) ==12768== by 0x100493796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib) ==12768== by 0x10048D485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib) ==12768== by 0x10062910E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib) ==12768== by 0x100629458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib) ==12768== by 0x1001599DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib) ==12768== by 0x100017A1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==12768== by 0x100017C1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==12768== by 0x1000134A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==12768== by 0x100013440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==12768== by 0x100012523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==12768== by 0x1000125B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==12768== Address 0x10488ac6c is on thread 1's stack ==12768== in frame #2, created by task_set_special_port (???:) ==12768== Uninitialised value was created by a stack allocation ==12768== at 0x1006290A6: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib) ==12768== ==12768== ==12768== HEAP SUMMARY: ==12768== in use at exit: 18,144 bytes in 162 blocks ==12768== total heap usage: 178 allocs, 16 frees, 24,288 bytes allocated ==12768== ==12768== LEAK SUMMARY: ==12768== definitely lost: 3,456 bytes in 54 blocks ==12768== indirectly lost: 0 bytes in 0 blocks ==12768== possibly lost: 72 bytes in 3 blocks ==12768== still reachable: 200 bytes in 6 blocks ==12768== suppressed: 14,416 bytes in 99 blocks ==12768== Rerun with --leak-check=full to see details of leaked memory ==12768== ==12768== For counts of detected and suppressed errors, rerun with: -v ==12768== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) 

    No entiendo esta parte de la traza:

     ==12768== Syscall param msg->desc.port.name points to uninitialised byte(s) ==12768== at 0x10049434A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib) ==12768== by 0x100493796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib) ==12768== by 0x10048D485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib) ==12768== by 0x10062910E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib) ==12768== by 0x100629458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib) ==12768== by 0x1001599DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib) ==12768== by 0x100017A1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==12768== by 0x100017C1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) ==12768== by 0x1000134A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==12768== by 0x100013440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==12768== by 0x100012523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld) ==12768== by 0x1000125B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) ==12768== Address 0x10488ac6c is on thread 1's stack ==12768== in frame #2, created by task_set_special_port (???:) ==12768== Uninitialised value was created by a stack allocation ==12768== at 0x1006290A6: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib) 

No entiendo por qué el resumen del montón es tan grande (178 asignaciones, 16 liberaciones, 24,288 bytes asignados) de mi simple retorno (0); progtwig.

Valgrind tiene un sistema para suprimir errores. Las reglas de supresión se especifican en archivos especiales, por ejemplo $PREFIX/lib/valgrind/default.supp . Los usuarios pueden crear sus propias reglas utilizando --gen-suppressions=full , que imprimirá una regla de supresión para cada error encontrado. El usuario puede personalizarlo a sus propias necesidades.

Hice esto por el error en cuestión, ¡y funciona muy bien! No es necesario instalar versiones inestables. Esta también es una buena herramienta en el cinturón si te topas con otros errores reportados que te gustaría ignorar.

~/.valgrind.supp este archivo como ~/.valgrind.supp .

 # false positive for any executable (it seems) # macOS 10.12.6 # valgrind 3.13.0 { libtrace initialization false positive Memcheck:Param msg->desc.port.name fun:mach_msg_trap fun:mach_msg fun:task_set_special_port fun:_os_trace_create_debug_control_port fun:_libtrace_init } 

# comienza un comentario y {} denota una regla. La primera línea es el nombre de la regla. El segundo dice qué herramienta y tipo de error suprimir. Param significa inválido syscall param, y la siguiente línea muestra el parámetro para suprimir los errores. Las siguientes líneas comienzan con fun: significa que esta regla de supresión solo se aplica en mach_msg_trap cuando es llamada por mach_msg llamada por task_set_special_port y así sucesivamente. De esta manera solo suprimimos el error en este caso muy específico donde Valgrind confunde la inicialización de libtrace con un error.

Valgrind usará esta regla si proporciona el argumento --suppressions=$HOME/.valgrind.supp en la línea de comando, o lo pone en $VALGRIND_OPTS o ~/.valgrindrc .

  • Suprimiendo errores [Valgrind]
  • Configurando las opciones predeterminadas [Valgrind]
  • Escribiendo archivos de supresión [Memcheck]
  • Cómo hacer el archivo de supresión de Valgrind [wkWiki]

Acabo de verificar el estado del error aquí y parece estar resuelto, así que simplemente verifiqué la confirmación y comstackción correspondientes. Resuelve el problema de los bytes no inicializados, pero se combina para crear nuevos problemas: ¿MACH_SEND_TRAILER no manejado?

1) clonar twig maestra

 $ git clone git://sourceware.org/git/valgrind.git 

2) parchelo con el arreglo

 $ cd valgrind $ git checkout 128fd6e 

3) configurar comstackr e instalar como de costumbre, instrucciones aquí

4) probarlo con un progtwig simple

 $ cd /bin $ ./valgrind ls -l ==19116== Memcheck, a memory error detector ==19116== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==19116== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==19116== Command: ls -l ==19116== --19116-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --19116-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --19116-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) --19116-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times) total 552 -rwxr-xr-x 1 user student 41642 Sep 11 15:55 callgrind_annotate -rwxr-xr-x 1 user student 12020 Sep 11 15:55 callgrind_control -rwxr-xr-x 1 user student 32174 Sep 11 15:55 cg_annotate -rwxr-xr-x 1 user student 10422 Sep 11 15:55 cg_diff -rwxr-xr-x 1 user student 29964 Sep 11 15:55 cg_merge -rwxr-xr-x 1 user student 24402 Sep 11 15:55 ms_print -rwxr-xr-x 1 user student 24468 Sep 11 15:55 valgrind -rwxr-xr-x 1 user student 39048 Sep 11 15:55 valgrind-di-server -rwxr-xr-x 1 user student 15056 Sep 11 15:55 valgrind-listener -rwxr-xr-x 1 user student 40216 Sep 11 15:55 vgdb ==19116== ==19116== HEAP SUMMARY: ==19116== in use at exit: 136,779 bytes in 225 blocks ==19116== total heap usage: 420 allocs, 195 frees, 202,112 bytes allocated ==19116== ==19116== LEAK SUMMARY: ==19116== definitely lost: 0 bytes in 0 blocks ==19116== indirectly lost: 0 bytes in 0 blocks ==19116== possibly lost: 72 bytes in 3 blocks ==19116== still reachable: 114,861 bytes in 71 blocks ==19116== suppressed: 21,846 bytes in 151 blocks ==19116== Rerun with --leak-check=full to see details of leaked memory ==19116== ==19116== For counts of detected and suppressed errors, rerun with: -v ==19116== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) 

La misma prueba realizada en linux ubuntu 16.04, con valgrind 3.11.0 proporciona una salida limpia.