23

Question has been asked before and I see bug report on ddd newsgroups but none of the suggested solutions work for me.

It comes up but when you try doing anything like opening a file it hangs with the message "waiting until GDB gets ready."

A crucial fact, reported by others too, is that it works fine for some users and not others. I've compared the environments and can't find any significant differences. Any suggestions will be most appreciated.

rocky
  • 7,226
  • 3
  • 33
  • 74
c-urchin
  • 4,344
  • 6
  • 28
  • 30
  • it might not be a bad idea to post the stuff that you've tried even if it didn't work, or possibly even link to the related bug report(s) – Daniel DiPaolo May 26 '10 at 14:49
  • point taken. I tried: removing .gdbinit. Changing the prompt via .gdbinit to "(gdb) " (trailing space supposed to be significant). I removed my initrc. None worked. Here are links to bug reports and suggested fixes (which for me did not work): http://bugs.gentoo.org/show_bug.cgi?id=93543#c10 http://osdir.com/ml/debugging.ddd.bugs/2003-02/msg00005.html – c-urchin May 27 '10 at 14:09

8 Answers8

40

Encountered this problem too. The easy solution as posted above is to delete the init file in the ~/.ddd/ directory.

But that means all your customizations will be gone. So I started hunting for the real cause. I observed that the problem only occurs after I have used the "GDB Settings" dialog. Once you opened this dialog the init file mentioned above will grow because a lot of gdb settings will be stored there.

After shrinking those additional lines step by step I found the "offending line". The problem is caused by the setting for extended-prompt. After opening the GDB settings dialog this line will read like

set extended-prompt not set\n\

This "not set" is what gdb will report on "show extended-prompt". Unfortunatley "set extended-prompt is sort of buggy in gdb, so if I enter "set extended-prompt not set" in a gdb running from a shell without ddd involved gdb will lockup as well.

It looks like the only safe way of setting the extend-prompt is when it contains the string "(gdb)". So I modified the offending line in the init file and now it reads like this:

set extended-prompt (gdb) \n\

With this setting I do not encounter the problem any longer. Hope that helps in your case too.

Alessandro Pezzato
  • 8,603
  • 5
  • 45
  • 63
Rainer König
  • 501
  • 4
  • 3
29

Removing ~/.ddd seams to solve the problem.

dzonder
  • 464
  • 4
  • 5
  • Clean and simple. This must be spread to the world, I had almost give up **ddd** before seeing this – albfan Oct 19 '12 at 02:06
  • 1
    Solved the problem for me too. Once. Then the problem appeared again. And then it solved it again. And so on. In short, I have to remove ~/.ddd every time I call ddd. – Alexey Bobrick Jul 19 '17 at 16:38
10

Doing a Ctrl+D, then choosing "Restart DDD" seems to work for me.

hmogal
  • 101
  • 1
  • 2
  • great solution! – Francesco Taioli Jul 06 '18 at 12:53
  • Thank you for this! I have tried the other two solutions above with some success over the years, but this has turned out to be the easiest and most reliable. I used to remove .ddd and I kept a tar file of a "clean" .ddd with my preferred settings to use after deleting .ddd, but that was still cumbersome. The extended-prompt approach worked for me - but not always. So good ole' Ctrl+D is working out great! – arr_sea May 06 '20 at 18:12
  • Update: Since learning about the Ctrl+D approach, that's been my go-to. However, today I ran into a situation where ddd wasn't responding to Ctrl+D (or Ctrl+C). I could still do "File -> Restart" via the menu, but that didn't fix it either. In this case, following the instructions for modifying the `extended-prompt` line (above) did the trick. I guess it's good to have both tools, as I've had cases where either one or the other didn't do the trick. – arr_sea Jul 20 '20 at 21:34
5

The problem arises when opening the GDB Settings... window, even without touching any setting.

Because removing the entire ~/.ddd/ configuration directory every time is not a way to go if you have customized your DDD environment, I have found a solution to fix the ~/.ddd/init file that could help you too without removing the entire configuration.

Close DDD and open with your text editor the file

~/.ddd/init

Search the line

set extended-prompt not set\n\

and remove it or replace it with

set extended-prompt \n\

Save and run DDD. It will start as it should.

Because this task can be tedious to repeat every time, especially if you change gdb settings quite often like me, I suggest you to create an alias in your shell environment like this.

alias fix-ddd="sed '/not set/d' -i $HOME/.ddd/init"

This last approach has the advantage that it will work for any bugged setting in the init file, without your specific intervention.


If you don't want to use the cli to fix the init file another approach is to edit the init file as suggested previously and if it happens to you to open for any reason the GDB Settings... panel then remember to disable in the Edit menu the option Save Options and leave it disabled until the next DDD restart.


For the sake of completeness (as stated by @hmogal) hitting

CTRL+d

during the GDB hanging kills GDB and restarts it allowing use DDD. Unfortunately this approach is not a good solution because it erases the entire GDB configuration inside the init file, even settings specifically tuned by you. So pay attention.


Everything tested with DDD 3.2.12.

Daniele Orlando
  • 2,692
  • 3
  • 23
  • 26
2

I think removing the init file inside .ddd will also solve this issue. No need to remove the entire .ddd folder. I tried it and it worked !

Also, if you extensively modify the ddd default options such as Buttons and Graph Displays, you can move your init file to outside this folder and then copy some of the options back to the init file created by ddd by default.

Note: When you restart ddd after removing init file, it will create the default init file.

Decipher
  • 71
  • 1
  • 2
1

If the issue persists, the following workaround may help:

  • open ddd as you would normally (eg. ddd --debugger bashdb script.sh)
  • type exit in the lower pane of ddd

This seems to kill one instance of bashdb, and then another instance of bashdb seems to run. This 2nd instance of bashdb seems to work fine, with the bash-script source finally appearing in the top-pane and allowing you to step-through and debug.

Calin
  • 2,110
  • 1
  • 21
  • 36
1

Using Ctrl+D pops up a dialog box asking to restart GDB which fixes the issue. In my case deleting ~/.ddd or init file in this particular folder didn't help.

0

Decipher's suggestion of simply deleting the init file worked for me as well.

And for those that don't know, ~/.ddd is the .ddd folder in your home directory.

samayo
  • 16,163
  • 12
  • 91
  • 106
cgrey8
  • 1