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

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

[rw at firstpr dot com.au]

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.

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

[rw at firstpr dot com.au]

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

--- Comment #1 from Robin Whittle <rw at firstpr dot com.au> ---
Created attachment 8412
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8412&action=edit
The 41551 byte printers.py file

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

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

[rw at firstpr dot com.au]

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

--- Comment #2 from Robin Whittle <rw at firstpr dot com.au> ---
This message concerns the configuration items for building this particular gdb
executable, and the printers.py arrangements. "show configuration" returns
(spaces edited and/or removed by this Bugzilla system - I wish programs would
not steal my spaces!):

==

~"This GDB was configured as follows:\n configure
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu\n"

~" --with-auto-load-dir=$debugdir:$datadir/auto-load\n
--with-auto-load-safe-path=$debugdir:$datadir/auto-load\n"
~" --with-expat\n"
~" --with-gdb-datadir=/usr/local/share/gdb (relocatable)\n"
~" --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)\n"
~" --without-libunwind-ia64\n"
~" --without-lzma\n"
~" --with-python=/usr\n"
~" --without-guile\n"
~" --with-separate-debug-dir=/usr/local/lib/debug (relocatable)\n"
~" --without-babeltrace\n"
~"\n(\"Relocatable\" means the directory can be moved with the GDB
installation\ntree, and GDB will still find it.)\n"

==

I was not able to use .configure so as to build a gdb which returns
"--with-python=/usr/bin", which is where the python executables are. Googling
indicates this is the most common arrangement. I tried no equals sign and
"=yes", "=/usr/bin/", "--with-python=/usr/bin/python" and
"=/usr/bin/python2.7".

There are several python executables in /usr/bin and the python symlink there
points to python2.7.

As far as I know, everything is correct with printers.py, though when I attach,
in a later message, an HTML file with instructions on reproducing the problem,
you will see gdb at startup complaining about some python things. I have not
tried to understand this, and I suspect it is nothing to worry about, since gdb
is perfectly able to navigate the structure of this vector of vectors (using
the CLI command "print"), displaying all the leaf node contents, and can do the
same for lists, maps and a struct of three elements, each with an int, a vector
of strings and a map of string-float pairs.

I have just attached the printers.py I am using. It is a 41,551 printers.py
which is identical to the one which applies to this version of libstdc++:

https://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch/libstdc++-v3/python/libstdcxx/v6/printers.py

To ensure the command line instance of gdb (with which I am reproducing the
problems) is operating in the same way as the one Codelite runs, I run it while
Codelite is running its instance, and use the same configuration arrangements.
At startup, Codelite copies a printers.py which the Codelite installer
supplies:

/usr/share/codelite/gdb_printers/libstdcxx/v6/printers.py

to the the user directory:

/home/robin/.codelite/gdb_printers/libstdcxx/v6/printers.py

(I think this is a bad idea, since it frustrates a user who customizes this
file in this location.) Current release versions of Codelite use an earlier
printers.py, but the version I am using, as updated recently by Eran Ifran,
uses the 41,551 version which is appropriate for the libstdc++ 4.9 I am using.
(This would not suit all Codelite users - no particular printers.py will
necessarily suit all Codelite users, and one user might, in principle, require
different printers.py files if they are compiling with different versions of
libstdc++.)

Then Codelite generates an init file: /tmp/codelite_gdbinit.txt :

==

python
import sys
sys.path.insert(0, '/home/robin/.codelite/gdb_printers')

from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)

from qt4 import register_qt4_printers
register_qt4_printers (None)

from wx import register_wx_printers
register_wx_printers (None)

from boost.printers import register_printer_gen
register_printer_gen(None)

end

==

At the start of a debugging session, Codelite runs gdb with the following
command line, which causes it to use this init file and therefore load the
41551 byte printers.py. If this file is not in my user directory, then gdb is
incapable of pretty printing even a vector of ints.

gdb --command="/tmp/codelite_gdbinit.txt" --tty=/dev/pts/6 --interpreter=mi
"./02_STL_PP"

For my command line testing, I use the same as this, without the tty option.

Codelite, when it first runs gdb, somehow causes a printers.pyc file to appear
in /home/robin/.codelite/gdb_printers/libstdcxx/v6/ I am not sure how relevant
that is, but gdb behaves the same way on the command line without this .pyc
file.

I am confident that all is well with printers.py - but perhaps someone has
insight as to how there might be a problem, such as python versionitis, which
explains the trouble I am reporting.

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

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

[rw at firstpr dot com.au]

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

Robin Whittle <rw at firstpr dot com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rw at firstpr dot com.au

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

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

[rw at firstpr dot com.au]

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

--- Comment #3 from Robin Whittle <rw at firstpr dot com.au> ---
Created attachment 8413
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8413&action=edit
Testcase: how to reproduce problems with the test program

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

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

[rw at firstpr dot com.au]

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

--- Comment #4 from Robin Whittle <rw at firstpr dot com.au> ---
The third attachment "Testcase: ..." shows exactly how to reproduce the
problems with gdb on the command line, and discerns some patterns.

All the trouble seems to result from using -var-update on indices [0], [2], [4]
and above.  With [1] and [3] the command seems to work fine.

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