【发布时间】：2011-01-31 12:17:41
【问题描述】：
我有一个 C 代码在 64 位 CPU 处理器中运行时没有任何内存泄漏，但在 32 位处理器中显示泄漏。可能是什么原因。 GCC 4.1.2 是编译器，Debian 是操作系统。
【问题讨论】：
-
发布一些代码会有所帮助（并且会很有趣）。
标签： c gcc memory-leaks
【发布时间】：2011-01-31 12:17:41
【问题描述】：
这听起来很奇怪。但对我来说，回答太模糊了。由于您使用的是 Linux，我建议您只需在 Valgrind 下运行 32 位版本，并进行最大内存跟踪。
【讨论】：
请记住，即使您自己的代码相同，您仍然在运行两个不同的程序——它们链接到不同的运行时库。可能是您的代码的某些方面在一个运行时而不是另一个运行时触发了泄漏。如果是这种情况，它可以通过以下两种方式之一发生：
a) 你没有做坏事。问题出在 32 位运行时。
或
b) 你有问题，但 64 位运行时中的一些防御措施正在掩盖它。
【讨论】：
-
或者：你做错了什么，纯侥幸意味着未定义的行为对 64 位版本的影响是（显然）无害的，而对 32 位版本的影响是导致泄漏（例如，通过用 0 覆盖某处的指针，以便释放它无效）。可能不是 64 位版本是防御性的，只是由于堆栈/结构布局不同，64 位版本上被破坏的内存未被使用。
-
@Steve：似乎有道理，不幸的是微妙。
没有代码真的很难说。可能出错的事情
- 隐式转换。在大多数地方，窄数据类型被转换为
signed或unsigned。如果你对它们的宽度有隐含的假设，你可能会遇到各种各样的事情：溢出、未定义的行为、编译器特定的行为 - 缺少函数原型。老式的 C 假定它不知道的函数返回
int。如果实际上它返回一个指针（例如）你有麻烦了。 - 指向
int转换（或相反）的指针
您的编译器已经很老了。如果可能的话，您可能应该尝试获取更新的东西，或者尝试不同的东西，例如clang。
编译 -Wall -Wextra... 上的所有警告并处理您的代码，直到它完全没有任何警告。
如果您的问题仍然存在，请按照 @unwind 的建议使用 valgrind 运行它。
然后这里有一个具体的问题，所以我们可以帮助你。
【讨论】：