2017-07-23 4 views
9

Ich versuchte Valgrind 3.13 und 3.14 (auf MacOs 10.12.6) in sehr einfachen Projekt zu laufen, aber ich habe seltsame Fehler, wer ich nie zuvor in meinem Linux.Valgrind macOs und Fehler Syscall Param msg-> desc.port.name zeigt auf nicht initialisierte Byte

  1. Sehr einfaches C-Programm main.c:

    int main() { 
        return (0); 
    } 
    
  2. Compilation mit cc:

    $> cc main.c 
    
  3. Führen mein einfaches Programm mit valgrind:

    $> valgrind ./a.out 
    
  4. Ausgabe von 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) 
    

    ich diesen Teil der Spur nicht verstehen:

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

Ich verstehe nicht, warum die Haufen Zusammenfassung so groß (178 Allocs ist, 16 frees , 24288 Bytes zugewiesen) meiner einfachen Rückkehr (0); Programm.

+0

Ich habe das gleiche Problem (auf gleiche Version von macOS 10.12.6); es gibt eine ganze Menge mehr Nachrichten zurück, wenn Sie '--leak-check = full' enthalten – Nibor

+0

Ich habe die gleiche Frage. – theoden

+0

Ich erhalte den gleichen Fehler unter Mac OS X 10.12. Ich denke, dass es einen Patch dafür geben könnte? Siehe [dieser Fehler] (https://www.mail-archive.com/[email protected]/msg134624.html) – Petergavinkin

Antwort

1

Ich habe gerade den Bug-Status here überprüft und es scheint gelöst, also habe ich gerade das entsprechende Commit ausgecheckt und kompilieren. Es löst das Problem der nicht initialisierten Bytes, verursacht aber neue Probleme: unbehandeltes MACH_SEND_TRAILER?

1) Klon Master Zweig

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

2) es mit dem Update Patch:

$ cd valgrind 

$ git checkout 128fd6e 

3) konfigurieren Kompilieren und installieren Sie wie gewohnt, Anweisungen here

4) testen mit einem einfachen Programm

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

Der gleiche Test unter Linux Ubuntu 16.04, mit Valgrind 3.11.0 bietet eine saubere Ausgabe.

2

Valgrind verfügt über ein System zur Fehlerunterdrückung. Unterdrückungsregeln werden in speziellen Dateien angegeben, z. B. $PREFIX/lib/valgrind/default.supp. Benutzer können ihre eigenen Regeln erstellen, indem sie die --gen-suppressions=full Hilfe verwenden, die eine Unterdrückungsregel für jeden aufgetretenen Fehler ausgibt. Der Benutzer kann es dann an seine eigenen Bedürfnisse anpassen.

Ich habe dies für den Fehler in Frage, und es funktioniert gut! Keine Notwendigkeit, instabile Versionen zu installieren. Dies ist auch ein gutes Werkzeug im Gürtel, wenn Sie auf andere gemeldete Fehler stoßen, die Sie ignorieren möchten.

Ich speicherte diese Datei als ~/.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 
} 

# startet einen Kommentar und {} eine Regel bezeichnen. Die erste Zeile ist der Name der Regel. Die zweite sagt, welches Werkzeug und welcher Fehlertyp unterdrückt werden soll.Param bedeutet ungültiger Syscall-Parameter, und die nächste Zeile gibt den Parameter an, um Fehler für zu unterdrücken. Die folgenden Zeilen, beginnend mit fun:, bedeuten, dass diese Unterdrückungsregel nur in mach_msg_trap gilt, wenn sie von mach_msg aufgerufen wird und von task_set_special_port aufgerufen wird. Auf diese Weise unterdrücken wir nur den Fehler in diesem sehr speziellen Fall, in dem Valgrind die libtrace-Initialisierung für einen Fehler fehlerhaft macht.

Valgrind verwendet diese Regel, wenn Sie das Argument --suppressions=$HOME/.valgrind.supp in der Befehlszeile angeben oder in $VALGRIND_OPTS oder ~/.valgrindrc eingeben.

Verwandte Themen