【发布时间】：2010-11-01 19:18:35
【问题描述】：
当我通过单步调试我的程序时，有时需要很长时间才能完成该步骤。这在项目开始时没有发生，所以很可能是由于我添加了一些东西。你能给我指点如何解决这个问题吗？我确实注意到其中一个问题是由于主线程试图绘制一个小部件。我的应用程序是多线程的（1 个后台线程和 1 个主线程），所以我想知道它是否与此有关。感谢您的 cmets。
【问题讨论】：
标签： c++ multithreading qt gdb breakpoints
【发布时间】：2010-11-01 19:18:35
【问题描述】：
使用 gdb 只需 set scheduler-locking mode 即可获得所需的行为。
在这种情况下：“step 模式针对单步执行进行了优化。它通过在您单步执行时抢占当前线程来阻止其他线程“抢占提示”。其他线程只会很少（或永远不会）当你踏步时有机会跑步。”
【讨论】：
猜测：您的“后台线程”是否固定在接近 100% 的 CPU 利用率？
在主线程的行之间，在单步执行时，调试器将允许后台线程也“单步执行”。如果后台线程被挂钩，它可能运行的指令远不止几条指令，导致事情看起来没有响应。
如果您的第二个线程连续进行如此多的计算，则可能表明您的应用程序中存在另一个需要修复的问题。如果您控制了该线程，您可能会看到您的调试器处理得更好。
【讨论】：
-
我的程序实际上显示 0% cpu 使用率。当它绘制一个小部件时，我怀疑它是直接在视频卡上完成的。
-
补充：当断点需要时间返回时，我检查了 cpu 使用率，我发现我的应用程序没有任何问题，但是当断点没有返回时，gdb 确实上升了 96%。 （我的系统上还运行了一个虚拟机，它启用了 yield 功能我不知道这是否会产生影响）
-
你在什么平台上调试？我在我的 Windows 机器上运气不错，但在 Mac 上却很糟糕。拥有大量内存似乎会有所帮助。
我问了一个关于 Visual Studio 的非常相似的问题：VS2010 debugger takes an unreasonable amount of time
没有真正的答案。您也可以在此处找到有关 IDE 过去版本的类似问题。
【讨论】：