Eclipse C++ STL 中的调试中断
我是 Eclipse 调试新手。
我尝试调试我的应用程序以了解它的段错误在哪里。
问题是 Eclipse 破坏了 STL，这非常烦人。
例如：我在源文件的第 134 行创建了一个断点，效果很好 但如果我按 F6 进行“Step Over”，Eclipse/gdb 会中断下一行中使用 std::cout 的 basic_string 构造函数。
对此有任何提示吗？ 有没有 Eclipse 之类的配置选项？
I'm new to debugging with Eclipse.
I try to debug my app to know where it segfaults.
The problem is that Eclipse breaks within the STL, which is very annoying.
For example: I created a breakpoint in my source file on line 134, which works fine
but if I hit F6 for "Step Over", Eclipse/gdb breaks in basic_string constructor used in the next line with std::cout.
Any hints on this? Is there a configuration option for Eclipse or such?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
也许这就是它出现段错误的地方？
Perhaps that's where it segfaults?
我没有使用过 Eclipse，但我确信有一个“堆栈回溯”或“调用堆栈”视图，您可以使用它们来查看 STL 代码中最终的调用链。
I haven't used Eclipse but I'm sure there is a "stack backtrace" or "call stack" view that you can use to see the call chain that ended up in the STL code.
如果代码经过优化，那么它可能会在 stl 中中断。 尝试使用调试模式进行编译，它可能会有所帮助。
if the code is optimized then it might break in the stl. Try compiling using debug mode and it might help.
由于信息有限，我想到的是，
跨过 (F6) 找到位置
这正在发生。
不行，升级CDT到最新
版本并重试。
没有日食。
投入一堆 cerr 输出。
注意 cerr（未缓冲）不是
库特。
如果这些都不起作用，请发布更多详细信息。
Given limited information, this is what comes to mind,
stepping over (F6) to locate where
this is happening.
not work, upgrade CDT to the latest
version and try again.
without Eclipse.
throw in a bunch of cerr outputs.
Note cerr (which is not buffered) not
cout.
If none of this works post more details.
我有类似的问题。 这是关于内联函数（stl 引起的）。
您需要添加一些编译器标志来生成一些额外的调试信息。 如果您使用 gcc，请参阅 -g* 标志（-ggdb 用于 gdb 调试器合规性，它为您提供对该类型调试器的最体面的支持）。
您可能还想关闭优化。
PS我还不够清楚：这不是Eclipse的错，而是编译器/调试器的错。
I had similar problem. It's about inline functions (which stl cuases).
You need to add some compiler flags to generate some extra debug information. If you are using gcc see -g* flags (-ggdb for gdb debugger compliance, it gives you the most decent support for that types of debuggers).
Also you might want to turn off optimization.
P.s. I wasn't clear enough: it's not Eclipse's fault, it's compiler/debugger fault.