[Bug c++/18623] New: MI -var-update problems with vector of vectors

["rw at firstpr dot com.au" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18623

            Bug ID: 18623
           Summary: MI -var-update problems with vector of vectors
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: rw at firstpr dot com.au
  Target Milestone: ---

Created attachment 8411
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8411&action=edit
C++ source code to demonstrate difficulties gdb has with vector of vectors

This is a preliminary report.  This is based on gdb-7.9.50.20150702.tar.xz on
Intel/AMD Debian 8.1 64 bit with g++ 4.9 and libstdc++-4.9. I think the same
problem affects gdb-7.7.1 and intermediate versions, and occurs in the
TDM-GCC-64 release on Windows with gdb 7.8.1.

I discovered this with Codelite, and there might be similar problems with
NetBeans. I established that the problem is in gdb, since I can reproduce it
with gdb alone on the command line, with "-i mi".

My test file creates a variable vv2 which is a vector of 5 vectors, each with 2
ints, and then stops at a breakpoint. CLI commands (such as print) work fine
and show the full structure and values of all the leaf nodes. I think the
equivalent MI commands do the same, but the problems occur with -var-update and
-var-list-children.

If I use these for elements [2] or [4] (or any higher number if the outer
vector had more than 5 elements) then gdb produces an error message of the
form:

c-varobj.c:893: internal-error: cplus_describe_child: Assertion `access'
failed.

Any further commands to gdb fail. I am sure this response is invalid.

Assuming that elements [2], [4] etc. have not yet been the subject of
-var-update or -var-list-children commands, giving these two commands for the
following elements, in any order, elicits the following responses.

For element [0], the response to -var-update is "changelist=[]" and the
response to -var-list-children is "numchild="0",has_more="1".

I think both of these are invalid. They cause Codelite to behave as if the
first vector is empty, or does not really exist. I think the proper responses
would be as for elements [1] and [3].

For element [1] the response to -var-update is:

changelist=[{name="var1.[1]",in_scope="true",type_changed="false",displayhint="array",dynamic="1",has_more="1"}]

and the response to -var-list-children is:

numchild="2",displayhint="array",children=[child={name="var1.[1].[0]",exp="[0]",numchild="0",type="int",thread-id="1"},child={name="var1.[1].[1]",exp="[1]",numchild="0",type="int",thread-id="1"}],has_more="0"

Codelite uses these to send further commands, and gdb's responses appear to be
correct in that they enable Codelite to properly display the structure of
vv2[1], with the values of its two integer elements.

The same applies for element [3].

The result, for me as a Codelite user, is that I can see into elements 1 and 3,
provided I do not open up elements 2, 4 or higher. I cannot see anything in
element 0. Yet, in Codelite's gdb commandline (CLI) facility ("Output" pane), I
can still list the full structure with print, provided there have been no
errors due to accessing element [2], [4] etc.

I think C++ programming naturally and unavoidably involves ubiquitous use of
the Containers Library classes, starting with vectors of vectors. Yet I have
the impression that gdb at present is incapable of handling such code.

The same problems appear to apply to lists as well, but I have not tested that
via the command line.

More to come in the next day or so, but if anyone can point me to a related
bug, or give any explanation, I would appreciate it.

- Robin

-- 
You are receiving this mail because:
You are on the CC list for the bug.