之前已经问过问题，我看到了有关ddd新闻组的错误报告，但没有一个建议的解决方案适合我。
它出现了，但是当你尝试做一些事情，比如打开一个文件时，它会挂起“等待GDB准备就绪”的消息。
其他人报告的一个关键事实是，它对某些用户而不是其他用户都有效。我对环境进行了比较，但未发现任何显着差异。任何建议都将受到最高的赞赏。
答案 0 :(得分：26)
删除〜/ .ddd接缝以解决问题。
答案 1 :(得分：25)
也遇到了这个问题。上面发布的简单解决方案是删除〜/ .ddd /目录中的init文件。
但这意味着您的所有自定义都将消失。所以我开始寻找真正的原因。我观察到问题只发生在我使用＆＃34; GDB设置＆＃34;对话。打开此对话框后，上面提到的init文件将会增长，因为很多gdb设置将存储在那里。
在逐步收缩这些额外的行后，我找到了＃34;违规行＆＃34;。 问题是由扩展提示设置引起的。打开GDB设置对话框后，该行将显示为
set extended-prompt not set\n\
这＆＃34;未设置＆＃34;是gdb将报告的内容＆＃34; show extended-prompt＆＃34;。 Unfortunatley＆＃34;设置扩展提示 在gdb中有点像bug，所以如果我输入＆＃34;设置extended-prompt not set＆＃34;在没有ddd的shell中运行的gdb中，gdb也会锁定。
看起来设置扩展提示符的唯一安全方法是它包含字符串＆＃34;（gdb）＆＃34;。 所以我修改了init文件中的违规行，现在它的内容如下：
set extended-prompt (gdb) \n\
使用此设置我不再遇到问题。希望对你的情况也有帮助。
答案 2 :(得分：7)
执行Ctrl + D，然后选择＆＃34;重新启动DDD＆＃34;似乎对我有用。
答案 3 :(得分：3)
即使没有触及任何设置，打开GDB Settings...窗口时也会出现问题。
因为如果您已经自定义DDD环境，每次都不能删除整个~/.ddd/配置目录，我找到了一个解决方案来修复~/.ddd/init文件，它可以帮助您删除整个配置。
关闭DDD并使用文本编辑器打开文件
~/.ddd/init
搜索
行set extended-prompt not set\n\
和将其删除或将其替换为
set extended-prompt \n\
保存并运行DDD。它会以应有的方式开始。
因为这个任务每次重复都很繁琐，特别是如果你像我一样频繁更改gdb设置，我建议你在shell环境中创建一个别名。
alias fix-ddd="sed '/not set/d' -i $HOME/.ddd/init"
最后一种方法的优点是，它可以在init文件中的任何错误设置下工作，而无需您的特定干预。
如果您不想使用cli来修复init文件，另一种方法是按照之前的建议编辑init文件，如果您因任何原因打开GDB Settings...面板那么请记得在Edit菜单中禁用选项Save Options并将其禁用，直到下一次DDD重新启动。
为了完整性（如@hmogal所述）点击
CTRL+d
在GDB挂起期间杀死GDB并重新启动它允许使用DDD。不幸的是，这种方法不是一个好的解决方案，因为它会删除init文件中的整个GDB配置，甚至是您专门调整的设置。所以要注意。
使用DDD 3.2.12 测试的所有内容。
答案 4 :(得分：2)
我认为删除.ddd中的init文件也可以解决这个问题。无需删除整个.ddd文件夹。我试过了，它有效！
此外，如果您广泛修改ddd默认选项（如按钮和图表显示），则可以将init文件移动到此文件夹之外，然后将某些选项复制回ddd默认创建的init文件。
注意：在删除init文件后重新启动ddd时，它将创建默认的init文件。
答案 5 :(得分：1)
如果问题仍然存在，则以下解决方法可能有所帮助：
ddd --debugger bashdb script.sh）exit
这似乎杀死了一个bashdb实例，然后另一个bashdb实例似乎运行了。第二个bashdb实例似乎工作正常，bash-script源最终出现在顶层窗格中，允许您逐步调试。
答案 6 :(得分：1)
使用Ctrl + D会弹出一个对话框，要求重启GDB以解决问题。在我的情况下，删除此特定文件夹中的〜/ .ddd或init文件没有帮助。
答案 7 :(得分：0)
Decipher建议简单地删除init文件也适合我。
对于那些不知道的人， ~/.ddd 是您主目录中的 .ddd 文件夹。