我试图在非常简单的项目中运行valgrind 3.13和3.14(在macOs 10.12.6上(，但我得到了奇怪的错误，我以前从未在我的Linux中遇到过。
-
非常简单的C程序
main.c：int main() { return (0); } -
与
cc编译：$> cc main.c -
用
valgrind运行我的简单程序：$> valgrind ./a.out -
瓦尔格林德的产量：
==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)我不明白这部分跟踪：
==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)
我不明白为什么我的简单返回(0(的堆摘要如此之大(178个分配，16个空闲，分配24,288个字节(; 程序。
Valgrind 有一个抑制错误的系统。抑制规则在特殊文件中指定，例如$PREFIX/lib/valgrind/default.supp。用户可以使用--gen-suppressions=full辅助工具创建自己的规则，该辅助工具将为遇到的每个错误打印抑制规则。然后，用户可以根据自己的需要对其进行自定义。
我为有问题的错误做了这个，效果很好！无需安装不稳定的版本。如果您遇到其他想要忽略的报告错误，这也是腰带中的好工具。
我将此文件保存为~/.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
}
#开始注释，{}表示规则。第一行是规则的名称。第二个说明要抑制的工具和错误类型。Param表示无效的系统调用参数，下一行给出要抑制错误的参数。以下以fun:开头的行表示此抑制规则仅在由mach_msgtask_set_special_port调用时适用于mach_msg_trap。这样，我们只在这种非常特殊的情况下抑制错误，其中 Valgrind 将 libtrace 初始化误认为是错误。
如果您在命令行上提供参数--suppressions=$HOME/.valgrind.supp，或者将其放在$VALGRIND_OPTS或~/.valgrindrc中，Valgrind 将使用此规则。
- 抑制错误 [瓦尔格林德]
- 设置默认选项 [瓦尔格林德]
- 写入抑制文件 [内存检查]
- 瓦尔格林德抑制文件操作方法 [wkWiki]
我刚刚检查了这里的错误状态，它似乎已解决，所以我只是检查了相应的提交并编译。它解决了未初始化字节的问题，但接缝会产生新问题：未处理的MACH_SEND_TRAILER？
1( 克隆主分支
$ git clone git://sourceware.org/git/valgrind.git
2(使用修复程序修补它：
$ cd valgrind
$ git checkout 128fd6e
3(像往常一样配置编译和安装，说明在这里
4(用一个简单的程序进行测试
$ 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)
在 linux ubuntu 16.04 上完成的相同测试，valgrind 3.11.0 提供了干净的输出。