bugDDD - Bugs: bug #63928, Resource mismanagement causes...

 
 

bug #63928: Resource mismanagement causes DDD/GDB interaction to hang

Submitter:  None
Submitted:  Wed 15 Mar 2023 04:01:03 AM UTC
   
 
Category:  Gdb integration Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  3.3.12
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 17 Mar 2023 04:09:47 PM UTC, comment #2: 

This is a known bug in DDD 3.12. It is fixed in the current trunk and in the upcoming release 3.4.

Stefan Eickeler <eickeler>
Group administrator
Wed 15 Mar 2023 11:40:52 AM UTC, comment #1: 

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.

Ian Kirkham <expl_squirrel>
Group Member
Wed 15 Mar 2023 04:01:03 AM UTC, original submission:  

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.

Anonymous

 

(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

 

Carbon-Copy List
  • -email is unavailable- added by eager (Updated the item)
  • -email is unavailable- added by eickeler (Posted a comment)
  • -email is unavailable- added by expl_squirrel (Posted a comment)
  •  

    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.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-05-06 eager Open/ClosedOpen Closed
    2023-03-17 eickeler StatusNone Fixed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code