当 ddd “等待它准备就绪”时,gdb/dbx 在做什么?

发布于 2024-12-10 15:53:19 字数 359 浏览 1 评论 0原文

我使用 ddd 作为 C++ 程序的 gdb 和 dbx 的前端。

很多时候,在没有任何明显原因的情况下,我会尝试下一步,但它会挂起,并显示消息“等待 gdb 准备好”或“等待 dbx 准备好”。

有人知道他们正在做的事情需要很长时间并且没有产生明显的结果吗? 我可以阻止它发生吗?

请记住,已经加载了足够的内容,我很高兴在同一进程(并且在同一函数中)提前一分钟步进/下一分钟,因此无论他们正在做什么似乎都没有必要。此外,ddd 和 dbx 具有相同的行为模式(在许多不同的可执行文件和不同平台上)这一事实使我认为这是数据中的某些内容,而不是任一调试器中的错误。

I use ddd as a front-end for both gdb and dbx for C++ programs.

Quite often, without any apparent cause, I will try to next and it will hang with the message "Waiting for gdb to get ready" or "Waiting for dbx to get ready".

Does anybody know what it is that they're doing that takes forever and produces no apparent results? And can I stop it from happening?

Bear in mind that enough stuff has already been loaded that I have quite happily been stepping/nexting a minute earlier in the same process (and in the same function), so whatever they're doing doesn't seem to have been necessary for that. Also the fact that both ddd and dbx have the same pattern of behaviour (in many different executables and on different platforms) makes me think it's something in the data rather than a bug in either debugger.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

青萝楚歌 2024-12-17 15:53:19

GDB(这同样适用于 DBX)通过 MI 协议与 DDD 进行通信,MI 协议是命令行界面的标准化且明确的等效项。

备注:我的系统(Fedora 15)中的默认设置似乎是直接使用 CLI 进行通信,但我只注意到您用 --interpret=mi 描述的问题。

例如,以下是获取线程列表的相应输出:

(gdb) info threads 
  Id   Target Id         Frame   
2    Thread 0x7ffff7fd2700 (LWP 9191) "philosophers" 0x00000037dcc0b4c5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0  
1    Thread 0x7ffff7fd3720 (LWP 9182) "philosophers" 0x00000037dc8df461 in clone ()   from /lib64/libc.so.6

(gdb) -thread-info 
^done,threads=[
   {id="2",target-id="Thread 0x7ffff7fd2700 (LWP 9525)",name="philosophers",
    frame={level="0",addr="0x0000000000400b31",
           func="chopsticks_put",
           args=[{name="i",value="0"}],
           file="chopsticks.c",fullname="philosphers/chopsticks.c",line="70"},
    state="stopped",core="2"},
   {id="1",target-id="Thread 0x7ffff7fd3720 (LWP 9522)",name="philosophers",
    frame={...},
    state="stopped",core="1"
   }],current-thread-id="3"

因此,您在 DDD 中看到的内容将与 CLI 中提供的内容非常相似,只有“表示层”不同。

根据我的经验,大多数 GDB 命令都非常快,至少当它们不依赖于调试对象执行时(例如 next 超过 sleep(5))。所以你的问题有两种可能:

  • 通信中的错误:例如 DDD 错过了 ^done 标签或 GDB 忘记了,因此 DDD 徒劳地等待其请求的终止
  • DDD 询问GDB 用于大量数据,例如结构体的定义、函数位置或内存内容等(例如因为要监视的元素),因此需要一些时间才能获取这些信息由GDB计算并传输至DDD。

在 DDD 的底部有 GDB 控制台。尝试在其中输入一些 GDB 命令。如果 GDB 响应正确(我的情况),则意味着 DDD 不再与 GDB 同步。 (DDD 已经过时了,2009/02/11,而 MI 被 Eclise 广泛使用,所以我想我们知道该怪谁了……!)

GDB (and the same applies for DBX) communicate with DDD with the MI protocol, which is a standardize and unambiguous equivalent of the command-line interface.

Remark: the default in my system (Fedora 15) seems to be that they communicate directly using the CLI, but I only noticed the problem you describe with --interpret=mi.

For instance, here are the respective output to get the thread list:

(gdb) info threads 
  Id   Target Id         Frame   
2    Thread 0x7ffff7fd2700 (LWP 9191) "philosophers" 0x00000037dcc0b4c5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0  
1    Thread 0x7ffff7fd3720 (LWP 9182) "philosophers" 0x00000037dc8df461 in clone ()   from /lib64/libc.so.6

(gdb) -thread-info 
^done,threads=[
   {id="2",target-id="Thread 0x7ffff7fd2700 (LWP 9525)",name="philosophers",
    frame={level="0",addr="0x0000000000400b31",
           func="chopsticks_put",
           args=[{name="i",value="0"}],
           file="chopsticks.c",fullname="philosphers/chopsticks.c",line="70"},
    state="stopped",core="2"},
   {id="1",target-id="Thread 0x7ffff7fd3720 (LWP 9522)",name="philosophers",
    frame={...},
    state="stopped",core="1"
   }],current-thread-id="3"

So what you will see in DDD will be quite similar to what is available in the CLI, only the 'presentation layer' is different.

From my experience, most of GDB commands are very fast, at least when they don't depend on the debuggee execution (like a next over a sleep(5)). So there are two possibilities for your problem:

  • a bug in the communication: for instance a ^done tag is missed by DDD or forgotten by GDB, so DDD waits in vain for the termination of its request
  • DDD asks GDB for a lot of data, like the definition of structures, function locations or memory contents, etc. (for instance because of the elements you want to watch), so it will take some time for the information to be computed by GDB and transferred to DDD.

At the bottom of DDD you have the GDB console. Try typing some GDB commands in there. If GDB responds correctly (my case) it means that DDD is not synchronized with GDB anymore. (DDD is getting old, 2009/02/11, and MI is extensively used by Eclise, so I think we know who has to be blamed...!)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文