bug-ddd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: anonymous
Subject: [bug #63928] Resource mismanagement causes DDD/GDB interaction to hang
Date: Wed, 15 Mar 2023 00:01:05 -0400 (EDT)

URL:
  <https://savannah.gnu.org/bugs/?63928>

                 Summary: Resource mismanagement causes DDD/GDB interaction to
hang
                   Group: DDD
               Submitter: None
               Submitted: Wed 15 Mar 2023 04:01:03 AM UTC
                Category: Gdb integration
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
                 Release: 3.3.12
         Discussion Lock: Any


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Wed 15 Mar 2023 04:01:03 AM UTC By: Anonymous
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.







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63928>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]