Add a New Comment (Rich Markup)
This is a known bug in DDD 3.12. It is fixed in the current trunk and in the upcoming release 3.4.
The symptom I have seen is that some scenario arises that causes the ddd init file to be rewritten - much of the data for the rewrite is from enquiry commands to gdb for its disposition. The problem is that with subsequent versions of gdb over the years, ddd is not able to parse all the gdb reported settings that ddd tries to capture. The result I usually see is a value called "not set" against a prompt. When fed back into ddd and subsequently gdb the message passing between these jams up due to unexpected data. My workaround is to delete any lines with "not set" from the init file.
There is a seemingly random bug somewhere in the handling of the GDB resources that causes invalid VALUES to infect the default session file ~/.ddd/init in various settings. These infections do not ALWAYS cause DDD to stop communicating with GDB, but once they DO, DDD remains stuck thinking GDB is busy, while GDB has returned and is awaiting further commands. The specific issue is that GDB (in this case version 7.8.1) has somehow caused an explanatory message to be MISTAKEN (by DDD) as the actual current value for some resource. DDD then INSTALLS this value into the resource database, which ultimately finds its way into the ~/.ddd/init persistent storage when that session of DDD terminates. It is upon starting a NEW session that the issue occurs where the file is used to reinstate the previous settings, DEPENDING on the specific resource affected, this then CAN corrupt the ability for DDD to detect the completion of virtually ANY simple command. One observed resource exhibiting this behavior is "extended-prompt". When invoking the command "show extended-prompt" the response from GDB CAN BE "The extended prompt is not set.". DDD appears to process this by SETTING the resource to "not set". This in turn causes DDD to NOT RECOGNIZE further prompt responses from GDB because it is still looking for "(gdb) " which IS the present setting of the "prompt" resource. Quitting DDD then WRITES this invalid value to the "init" file, and all further attempts at running DDD then fail. However this particular resource is not the ONLY one that suffers from this cross-up of messages being installed AS values. It has been observed on several settings, but ALWAYS when GDB has elected to DESCRIBE the setting in English prose, rather than just PROVIDING the current setting. Further resources observed are "mem" and "remote exception-sequence", but I cant be certain there aren't others POSSIBLE. Nearly ANY attempt at adjusting ANY individual setting is sufficient to cause this corruption to occur, leading to an inability to debug should a changed setting (such as follow-fork-mode) be required (because we needed to trace the child, not the parent). While I recognize that the version of GDB may be somewhat dated, it IS a contemporary of the BASE distributed code for DDD which still appears to be circa 2009 as of this writing. Further note that SHOULD the init file be deleted, DDD is perfectly happy using its builtin default settings in its stead - BUT that severely curtails the usage of DDD to ONLY process as configured BY those default settings. I consider this unacceptable. While I attempted to debug this myself, my C++ skills are no where near my C skills, or I would have supplied a patch. This report represents my best effort, although I am disheartened by the seeming lack of activity displayed by the age of existing open bugs.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 2 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11