我有这个相对较大的数字应用程序代码，可能会运行几天并最终吐出一些数字。整个东西是用 C++ 编写的，利用了一堆 3rd-party 库，并使用 GCC 4.6 编译。该代码始终使用共享指针。
不幸的是，随着时间的推移，代码的内存消耗会增加，直到所有（共享）内存都用完，然后崩溃。从算法上讲，代码不应该随着时间的推移积累内存，所以某处会出现错误。
我确实通过 valgrind 的泄漏检查器运行了一个小例子，它报告一切都应该没问题。我的想法是共享指针可能会在某个地方无意中创建，从而防止在过程中释放不需要的数据（但这只是一个猜测）。
在一天结束的时候，我已经没有想法如何调试这样的东西了。有任何想法吗？
由于您已经拥有可用的 valgrind 工具套件，我建议您运行massif工具。
Massif 将跟踪内存分配来源，并且报告将指示您每个分配站点/函数创建了多少字节。这将帮助您了解内存爆炸的来源。
GNU libstdc++ 默认缓存与 STL 相关的内存分配，显然是出于微基准速度的原因。但是，当使用 tcmalloc 和 jemalloc 等分配器时，实际效果往往对速度和内存占用都非常不利。tcmalloc 通过在环境中设置 GLIBCPP_FORCE_NEW=1 和 GLIBCXX_FORCE_NEW=1 来禁用此行为（分别适用于libstdc++版本 3.3 和 3.4），但我知道没有其他分配器这样做。因此，在启动应用程序时设置适当的环境变量通常是个好主意。
即使您没有泄漏，您也可能面临内存碎片。
如果你在 Linux 上，我建议尝试jemalloc分配器。它在 Linux 上运行良好。它可以在许多架构上运行，我什至在 zLinux（IBM zSeries 大型机上）上也成功使用了它。它真的很容易使用——你甚至不需要重建你的应用程序或任何库，只需构建 jemalloc 并使用LD_PRELOAD这样的 set 启动你的应用程序：LD_PRELOAD=/usr/lib/libjemalloc.so <app>