操作系统相关的C ++内存泄漏？

CONTEXT

我在Linux下为我的跨平台库运行Valgrind 。 我试图看看这是否足够，或者如果我应该在Windows和Mac上运行dynamic代码分析

题

如果我的平台独立的 C ++代码不在Linux泄漏（根据Valgrind ），我可以假设它不在Windows和Mac上泄漏吗？ 如果不是，请提供一个独立于平台的C ++示例，不要在Linux （根据Valgrind ）泄漏，而是在Windows和/或Mac上泄漏（select像VC ++，GCC等那样的“常见”编译器）。

/ proc / $ pid / maps显示x86_64 linux上没有rwx权限的页面

Valgrind：禁用条件跳转（或整个库）检查

C ++ Winsock接受内存泄漏/资源泄漏

alsa – mem泄漏？

当客户端调用CoCreateInstance并且意外closures时，Out-proc COM Server内存泄漏

精确度（感谢评论和答案）

我感兴趣的是独立于平台的C ++代码（所以没有#ifdef等）;

我认为我拥有C ++代码，而不是第三方代码;

我认为Valgrind是基本事实，但我可以考虑其他工具。 我知道没有工具可以检测到所有的内存泄漏。

有没有一种方法来定位进程的哪一部分使用大部分内存，只查看生成的核心文件？

Upstart init正在泄漏内存，你怎么debugging它？

redirectstdio时Linux BASH内存泄漏

Debian上的Java本地内存泄漏

执行并发操作时执行内存泄漏操作/ exec.Command.Wait（）

您可以确定泛型代码没有泄漏，当然，如果您的应用程序体积适中，则很可能某些代码是特定于Linux的，其他特定于Windows的位以及特定于某些操作系统的某些部分X。

那些不是特定于Linux的部分当然不会被Valgrind测试。

所以，如果你有一些代码段：

#if LINUX char buffer[512]; #else char buffer = new buffer[2048]; #endif ... use buffer ...

那么你在Windows中有一个内存泄漏，但不是Linux。

显然，这是一个微不足道的例子，但是有时候类似的东西可能会潜入代码中。

当然，在一个操作系统中使用某种系统调用的可能性是“安全的”，不能“关闭”或以其他方式“告诉操作系统已经完成”，然后在另一个操作系统中出现问题。

另外，正如我之前指出的那样，Valgrind并不保证你没有使用内存的问题 – 它只能检测到如下内容：

void func() { char *p = new [1700]; ... // no free of p; }

要么

void func() { char *p = new [1700]; ... // No free. p = some_other_pointer; ... }

但不是：

void func() { vector<int> v; for(;;) v.push_back(1); }

因为记忆仍然是“拥有”的东西。 当然，这个例子是相当极端的，但是你可以在代码存储的地方有类似的东西，只是将越来越多的东西添加到存储中，而不会删除它们。

valgrind有助于发现缺陷，但不能保证正确性。

您的代码中仍然可能存在未定义的行为，而未定义的行为在不同的平台上可能会有不同的表现，包括在一个平台上泄漏内存，而不是在另一个平台上泄漏内存。

如果你有条件编译的代码（例如#if defined (OS_LINUX) ），那么你肯定需要确保每个平台的泄漏。

注：这不是一个完整的答案，但只是我想到的一个案例。