valgrind可能丢失，仍然可以到达并被valgrind抑制

Question

我的环境是MacOS，valgrind-3.13.0，g ++ Apple LLVM版本9.0.0（clang-900.0.38）

正如标题所述，代码如下：

#include <iostream>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>

#define MAP_SIZE 4096UL
#define MAP_MASK (MAP_SIZE - 1)

int main(int argc, char** argv) {
    int fd = open("a.txt", O_RDWR | O_SYNC);
    std::cout << "open return fd: " << fd << std::endl;
    unsigned long offset = 0ul;
    std::cout << "page_size is: " << getpagesize() << std::endl;
    void* map_base = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE, MAP_SHARED, fd, offset);

    if (map_base == (void*) -1) {
        close(fd);
        std::cout << "fatal" << std::endl;
        return -1;
    }
    void* virt_addr = static_cast<void*>(static_cast<char*>(map_base) + (offset & MAP_MASK));
    std::cout << "memory map at base address: " << map_base << std::endl;
    std::cout << "value at address: " << virt_addr << std::endl;
    std::cout << sizeof(virt_addr) << std::endl;
    memset(virt_addr, 0, sizeof(int) * 100);
    munmap(map_base, getpagesize());
    close(fd);
    map_base = nullptr;
    virt_addr = nullptr;
}

我使用以下命令来编译代码：

g++ mmap_test.cpp  -O0 -o mmap_test

并使用valgrind命令：

valgrind --tool=memcheck --leak-check=full ./mmap_test

结果如下：

==1725== Syscall param msg->desc.port.name points to uninitialised byte(s)
==1725==    at 0x10049734A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib)
==1725==    by 0x100496796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib)
==1725==    by 0x100490485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib)
==1725==    by 0x10062C10E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib)
==1725==    by 0x10062C458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib)
==1725==    by 0x10015C9DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==1725==    by 0x10001AA1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==1725==    by 0x10001AC1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==1725==    by 0x1000164A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==1725==    by 0x100016440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==1725==    by 0x100015523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==1725==    by 0x1000155B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==1725==  Address 0x10488dc8c is on thread 1's stack
==1725==  in frame #2, created by task_set_special_port (???:)
==1725==  Uninitialised value was created by a stack allocation
==1725==    at 0x10062C0A6: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib)

==1725== LEAK SUMMARY:
==1725==    definitely lost: 0 bytes in 0 blocks
==1725==    indirectly lost: 0 bytes in 0 blocks
==1725==      possibly lost: 72 bytes in 3 blocks
==1725==    still reachable: 4,296 bytes in 7 blocks
==1725==         suppressed: 17,928 bytes in 153 blocks

Answer 1

这已在Mac OS 上解决了Valgrind错误。

要摆脱此错误，您可以从当前资源构建Valgrind，请参阅https://bugs.kde.org/show_bug.cgi?id=379373。

另请参阅几乎重复的问题http://valgrind.org/downloads/repository.html。