使用 gdb 调试 C++ STL/Boost 的最佳实践

Debugging Best Practices for C++ STL/Boost with gdb

提问by amit

Debugging with gdb, any c++ code that uses STL/boost is still a nightmare. Anyone who has used gdb with STL knows this. For example, see sample runs of some debugging sessions in code here.

用gdb调试，任何使用STL/boost的c++代码仍然是一场噩梦。任何在 STL 中使用过 gdb 的人都知道这一点。例如，在此处查看代码中某些调试会话的示例运行。

I am trying to reduce the pain by collecting tips. Can you please comment on the tips I have collected below (particularly which ones you have been using and any changes you would recommend on them) - I have listed the tips is decreasing order of technicality.

我试图通过收集提示来减轻痛苦。您能否评论我在下面收集的技巧（特别是您一直在使用的技巧以及您建议对它们进行的任何更改）-我列出的技巧是按技术性递减顺序排列的。

• Is anyone using "Stanford GDB STL utils"and "UCF GDB utils"? Is there some such utils for boost data structures? The utils above do not seem to be usable recursively, for example for printing vector of a boost::shared_ptr in a legible manner within one command.
• Write your .gdbinit file. Include, for example, C++ related beautifiers, listed at the bottom of UCF GDB utils.
• Use checked/debug STL/Boost library, such as STLport.
• Use logging (for example as described here)

• 有人在使用“Stanford GDB STL utils”和“UCF GDB utils”吗？是否有一些用于提升数据结构的实用程序？上面的实用程序似乎不能递归使用，例如在一个命令中以清晰的方式打印 boost::shared_ptr 的向量。
• 编写您的 .gdbinit 文件。例如，包括在 UCF GDB 实用程序底部列出的 C++ 相关美化器。
• 使用检查/调试 STL/Boost 库，例如 STLport。
• 使用日志记录（例如此处所述）

Update: GDB has a new C++ branch.

更新：GDB 有一个新的 C++ 分支。

采纳答案by timday

Maybe not the sort of "tip" you were looking for, but I have to say that my experience after a few years of moving from C++ & STL to C++ & boost & STL is that I now spend a lotless time in GDB than I used to. I put this down to a number of things:

也许不是那种“小费”你要找的人，但我不得不说，几年后由C ++ STL移动到C ++＆提升＆STL的我的经验是，我现在花了大量的时间更少的GDB比我曾经。我把这归结为几件事：

• boost smart pointers (particularly "shared pointer", and the pointer containers when performance is needed). I can't remember the last time I had to write an explicit delete (delete is the "goto" of C++ IMHO). There goes a lot of GDB time tracking down invalid and leaking pointers.
• boost is full of proven code for things you'd probably hack together an inferior version of otherwise. e.g boost::bimapis great for the common pattern of LRU caching logic. There goes another heap of GDB time.
• Adopting unittesting. boost::test's AUTO macros mean it's an absolute doddle to set up test cases (easier than CppUnit). This catches lots of stuff long before it gets built into anything you'd have to attach a debugger to.
• Related to that, tools like boost::bindmake it easier to design-for-test. e.g algorithms can be more generic and less tied up with the types they operate on; this makes plugging them into test shims/proxies/mock objects etc easier (that and the fact that exposure to boost's template-tasticness will encourage you to "dare to template" things you'd never have considered before, yielding similar testing benefits).
• boost::array. "C array" performance, with range checking in debug builds.
• boost is full of great code you can't help but learn from

• boost 智能指针（特别是“共享指针”，以及需要性能时的指针容器）。我不记得上次我必须写一个显式删除（删除是 C++ 恕我直言的“转到”）。有很多 GDB 时间跟踪无效和泄漏的指针。
• boost 充满了经过验证的代码，用于您可能会在其他情况下将劣质版本组合在一起。egboost::bimap非常适合 LRU 缓存逻辑的常见模式。还有一大堆 GDB 时间。
• 采用单元测试。 boost::test的 AUTO 宏意味着设置测试用例绝对是轻而易举的（比 CppUnit 更容易）。早在它被内置到你必须附加调试器的任何东西之前，它就会捕获很多东西。
• 与此相关的是，诸如此类的工具boost::bind可以更轻松地进行测试设计。例如，算法可以更通用，并且与它们操作的类型的联系更少；这使得将它们插入到测试垫片/代理/模拟对象等中变得更加容易（而且事实上，暴露于 boost 的模板tasticness 会鼓励你“敢于模板化”你以前从未考虑过的东西，产生类似的测试好处）。
• boost::array. “C 数组”性能，在调试版本中进行范围检查。
• boost 充满了很棒的代码，你会忍不住从中学习

回答by Mr.Ree

You might look at:

你可能会看：

Inspecting standard container (std::map) contents with gdb

使用 gdb 检查标准容器 (std::map) 内容

回答by jpalecek

I think the easiest and most option is to use logging (well I actually use debug prints, but I think that's not a point). The biggest advantage is that you can inspect any type of data, many times per program execution and then search it with a text editor to look for interesting data. Note that this is very fast. The disadvantage is obvious, you must preselect the data which you want to log and places where to log. However, that is not such a serious issue, because you usually know where in the code bad things are happening (and if not, you just add sanity checks here and there and then, you will know).

我认为最简单和最多的选择是使用日志记录（我实际上使用调试打印，但我认为这不是重点）。最大的优点是您可以检查任何类型的数据，每次程序执行多次，然后使用文本编辑器搜索它以查找有趣的数据。请注意，这非常快。缺点很明显，必须预先选择要记录的数据和记录的位置。然而，这并不是一个严重的问题，因为您通常知道代码中哪里发生了不好的事情（如果没有，您只需在这里和那里添加健全性检查，然后您就会知道）。

Checked/debug libraries are good, but they are better as a testing tool (eg. run it and see if I'm doing anything wrong), and not as good at debugging a specific issue. They can't detect a flaw in user code.

检查/调试库很好，但它们作为测试工具更好（例如，运行它并查看我是否做错了什么），而不是调试特定问题。他们无法检测到用户代码中的缺陷。

Otherwise, I use plain GDB. It is not that bad as it sounds, although it might be if you are scared by "print x" printing a screenful of junk. But, if you have debugging information, things like printing a member of a std::vectorwork and if anything fails, you still can inspect the raw memory by the xcommand. But if I know what I'm looking for, I use option 1 - logging.

否则，我使用普通的 GDB。听起来并没有那么糟糕，但如果您被“ print x”打印一屏垃圾吓到了，情况可能会如此糟糕。但是，如果你有调试信息，比如打印一个std::vector作品的成员，如果有任何失败，你仍然可以通过x命令检查原始内存。但是如果我知道我在寻找什么，我会使用选项 1 - 日志记录。

Note that the "difficult to inspect" structures are not only STL/Boost, but also from other libraries, like Qt/KDE.

请注意，“难以检查”的结构不仅来自 STL/Boost，还来自其他库，如 Qt/KDE。