memory - 如何调试 Rust 中的内存问题？

Question

我希望这个问题不要过于开放。我遇到了 Rust 的内存问题，我得到了 an "out of memory" from calling next on an Iterator trait object .我不确定如何调试它。打印品只把我带到了失败发生的地步。我对其他工具不太熟悉，例如 ltrace ，所以尽管我可以创建跟踪(231MiB，pff)，但我真的不知道如何处理它。这样的痕迹有用吗？我会更好地获取 gdb/lldb 吗？还是 Valgrind？

Answer 1

一般来说，我会尝试采用以下方法:

1. 减少样板文件:尝试缩小 OOM 问题的范围，这样您就没有太多额外的代码。换句话说:你的程序崩溃得越快越好。有时也可以删除一段特定的代码并将其放入额外的二进制文件中，仅用于调查。

2. 减少问题大小:将问题从 OOM 降低为简单的“内存过多”，这样您就可以知道某些部分浪费了一些东西，但不会导致 OOM .如果很难判断您是否看到问题，您可以降低内存限制。在 Linux 上，这可以使用 ulimit 来完成:

   ulimit -Sv 500000  # that's 500MB
   ./path/to/exe --foo
   

3. 信息收集:如果您的问题足够小，您就可以收集噪音水平较低的信息。您可以尝试多种方法。请记住使用调试符号编译您的程序。关闭优化也可能是一个优势，因为这通常会导致信息丢失。两者都可以通过在编译期间不使用 --release 标志来存档。

   • 堆分析: 一种方法是使用 gperftools :

     LD_PRELOAD="/usr/lib/libtcmalloc.so" HEAPPROFILE=/tmp/profile ./path/to/exe --foo
     pprof --gv ./path/to/exe /tmp/profile/profile.0100.heap
     

     这向您展示了一个图表，它象征着程序的哪些部分占用了多少内存。参见 official docs了解更多详情。

   • rr: 有时很难弄清楚到底发生了什么，尤其是在创建配置文件之后。假设您在第 2 步中做得很好，您可以使用 rr :

     rr record ./path/to/exe --foo
     rr replay
     

     这将产生一个具有超能力的 GDB。与普通调试 session 的不同之处在于，您不仅可以continue，还可以reverse-continue。基本上，您的程序是从您可以根据需要来回跳转的录音中执行的。 This wiki page为您提供了一些额外的例子。需要指出的一件事是 rr 似乎只适用于 GDB。

   • 良好的旧式调试:有时您得到的跟踪和记录仍然太大。在这种情况下，您可以(结合 ulimit 技巧)只使用 GDB 并等待程序崩溃:

     gdb --args ./path/to/exe --foo
     

     您现在应该得到一个正常的调试 session ，您可以在其中检查程序的当前状态。 GDB 也可以使用 coredumps 启动。该方法的一般问题是您无法及时返回并且无法继续执行。所以您只能看到当前状态，包括所有堆栈帧和变量。如果需要，您也可以在这里使用 LLDB。

4. (潜在)修复 + 重复: 在了解可能出错的地方后，您可以尝试更改代码。然后重试。如果仍然无效，请返回第 3 步并重试。