由于内存泄漏，我遇到了崩溃(但它在 7 层深处，它只是遍历链表 - 那里没有分配)。
它是相当可重现的，几乎每天都可以重现，所以我总能得到一个新的核心文件。我花了最后 3-5 天的时间检查代码，配对分配/取消分配，但似乎无法找到导致它的地方，因为遗留 C 应用程序很大，到处都是 memcpy/alloc/calloc。坦率地说，一个错误的 memcpy 就是它可能需要的全部。
我经历了在本地编译 Valgrind 的努力，期待在它开始的地方得到一些很好的跟踪，但 Valgrind 只是让机器无法操作，例如必须在服务器机房手动重启，因为连ssh都不能用。由于 Valgrind，我们基本上失去了两天的调试时间，所以我不能第三次使用它(除非 Memcheck 可以以某种方式处理核心文件，也许吧？)
是否有其他工具可以帮助我分析核心文件中的内存泄漏？带有打印命令的 gdb 并不是很有帮助。
更具体地说，一些核心文件确实很大——1.5GB(虽然它们不应该超过 0.3GB)，所以我希望得到一份占用内存最多的前 2-3 名违规者的列表(这会给我直接提示下一步看哪里)。
有什么想法吗？
哦，至于稳定性——它可以在崩溃之前正确处理大约一百万(左右)的数据请求(有时是几百万)，所以仅仅在通常崩溃的地方放置一个断点是不可能的问题。
最佳答案
我会尝试创建一个测试输入集来启动系统，运行大量事务，然后以受控(即所有内容都应该清理)的方式将其关闭。在 valgrind 下运行那个小套件，它至少应该给你一些东西去追求。如果它是一个较旧的系统，您可能会遇到误报。如果到那时您还没有找到它，您将需要进行更多样化的测试。
顺便说一句，当运行较小的测试时，您可以限制进程大小(ulimit/limit)以避免大量内存镜像和相关的系统稳定性问题。
关于您可以使用 gdb(或其他工具)从核心文件中找到内存泄漏吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25941158/