Valgrind macOs i błąd Syscall param msg-> desc.port.name wskazuje na niezainicjowany bajt (y)

Question

Próbowałem uruchomić valgrind 3.13 i 3.14 (na Mac OS 10.12.6) w bardzo prostym projekcie, ale dostałem dziwny błąd, który nigdy wcześniej nie dostałem się do mojego Linux-a.

1. Bardzo prosty program w C main.c:

   int main() { 
       return (0); 
   } 
   

2. Kompilacja z cc:

   $> cc main.c 
   

3. uruchomić mój prosty program z valgrind:

   $> valgrind ./a.out 
   

4. Wyjście 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) 
   

   Nie rozumiem tej części śladu:

   ==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) 
   

Nie rozumiem dlaczego podsumowanie sterty jest tak duża (178 ALLOCS, 16 FreeS , 24 288 bajtów przydzielonych) mojego prostego powrotu (0); program.

Answer 1

Właśnie sprawdziłem status błędu here i wygląda na to, że został rozwiązany, więc właśnie sprawdziłem odpowiedni commit i skompilowałem. Rozwiązuje problem niezainicjowanych bajtów, ale szwów, aby stworzyć nowe problemy: nieobsługiwane MACH_SEND_TRAILER?

1) klon mistrz Branża

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

2) załatać je z fix:

$ cd valgrind 

$ git checkout 128fd6e 

3) skonfigurować skompilować i zainstalować jak zwykle, instrukcje here

4) Badanie to z prostym programem

$ cd <install-folder>/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) 

Ten sam test wykonany na Ubuntu Linux 16.04, z Valgrind 3.11.0 zapewnia czyste wyjście.

Answer 2

Valgrind ma system do tłumienia błędów. Reguły supresji są określone w plikach specjalnych, na przykład $PREFIX/lib/valgrind/default.supp. Użytkownicy mogą tworzyć własne reguły, korzystając z pomocy --gen-suppressions=full, która wydrukuje regułę tłumienia dla każdego napotkanego błędu. Użytkownik może następnie dostosować go do własnych potrzeb.

Zrobiłem to dla danego błędu i działa świetnie! Nie trzeba instalować wersji niestabilnych. Jest to również dobre narzędzie w przypadku napotkania innych zgłoszonych błędów, które chcesz zignorować.

Zapisałem ten plik jako ~/.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 
} 

# rozpoczyna komentarz i {} oznaczają regułę. Pierwsza linia to nazwa reguły. Drugi mówi, które narzędzie i typ błędu tłumić.Param oznacza niepoprawny parametr syscall, a następna linia podaje parametr tłumienia błędów dla. Poniższe linie rozpoczynające się od fun: oznaczają, że ta reguła tłumienia dotyczy tylko mach_msg_trap, gdy jest wywoływana przez mach_msg, wywoływana przez task_set_special_port i tak dalej. W ten sposób pomijamy tylko błąd w tym szczególnym przypadku, w którym Valgrind błędnie inicjuje libtrace z powodu błędu.

Valgrind użyje tej reguły, jeśli podasz argument --suppressions=$HOME/.valgrind.supp w wierszu poleceń lub umieścisz go w $VALGRIND_OPTS lub ~/.valgrindrc.

• Suppressing errors [Valgrind]
• Setting default options [Valgrind]
• Writing suppression files [Memcheck]
• Valgrind Suppression File Howto [wkWiki]