使用memcpy for 64位linux可以将内容归零

我陷入了一个奇怪的问题。我有一个使用gyp项目创建的exe，并且支持common.gypi为32位和64位linux构建exe。但是，当我为64位linux构建时，在代码中的某个点调用memcpy时，内容会被置零。使用-m32标志构建32位平台不会导致此问题。我怀疑这些头文件可能有问题，因为该项目的头文件在32位和64位平台上都很常见。有人能提供一些如何解决这个问题的建议吗？二进制文件是动态链接的，并使用GLIBC lgcc、lc和lm。在此领域的任何指点都非常感谢。 我很乐意提供所需的任何其他信息。 谢谢

更新：一小段代码片段： 这是代码的基本片段：

dst->flags           = src->flags;
src->b = dst->b;
and few more assignments
memcpy(dst, src, size here is 152);
size of dst is 224 and size of src is 496. 

---

问题在于，调用memcpy后，最初复制到dst的标志值变为零。为32位构建时，同样的逻辑也可以正常工作。

请仔细阅读的文档。不允许源区域和目标区域重叠（否则会重叠）。编译时不要忘记启用所有警告和调试信息（

gcc-Wall-Wextra-g

）

您可能希望使用

---

要调试此类问题，您可以使用

gdb

调试器中的

watch

命令设置一个观察点，并且使用最近的调试器可以使用

-fsanize=address

作为编译标志。或者等等。

不可能回答如此不具体的问题。Memcpy复制内存，这就是它的全部，不管发生什么。如果它看起来没有-在其他地方有一个bug。你可以使用valgrind来追踪内存访问错误。实际上，我将我的32位设置移植到了64位，我所做的只是从64位版本的项目中删除-m32标志，我希望这会起作用。我可能可以给valgrind一个机会，但它不应该用来确定内存泄漏吗？我也尝试通过include字符串头文件直接在函数中使用memcpy，但仍然没有解决这个问题。我唯一怀疑的可能是因为src和dest的大小不同，并且在某些地方定义可能会弄乱结构。如果问题以前不明显，并不意味着它不存在。或者代码不适合64位方案，例如，它意味着sizeof（size\u t）==sizeof（int）。Valgrind有很多工具，这里你需要的一个是memcheck。谢谢@keltar：让我试一下，memcheck工具没有任何意义，除了几个警告“有条件的跳转或移动取决于未初始化的值”，这也不是我正在调查的领域…所有公平点。顺便说一下，Valgrind报告了memcpy重叠。