What is gdb/dbx doing when ddd is "waiting for it to get ready"?

Question

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.

Answer 1

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...!)