gdb: Guard against undefined behaviour in mi-vla-fortran.exp
authorAndrew Burgess <andrew.burgess@embecosm.com>
Fri, 11 Dec 2015 19:58:50 +0000 (19:58 +0000)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Mon, 1 Feb 2016 18:05:35 +0000 (18:05 +0000)
commit37a8db1a336ce78a46bf7f303e47e17b2a1bf694
tree3628ce9554c44ac050025e23890b24d42207c2d2
parent5fdf6324fafd60f967e2e8323fdacf84b1bfcea3
gdb: Guard against undefined behaviour in mi-vla-fortran.exp

The test gdb.mi/mi-vla-fortran.exp reveals an issue with the DWARF
generated by gfortran.

In the test a pointer variable 'pvla2' is created:
    real, pointer :: pvla2 (:, :)

Initially this variable will be unassociated, so something like this:
    l = associated(pvla2)

should return false.

In the test gdb stops at a point _before_ pvla2 is associated with
anything, and we then try to print pvla2, the expectation is that gdb
should reply <not associated>.

The problem is that the data the DWARF directs gdb to read (to identify
if the variable is associated or not) is not initialised until the first
time pvla2 is accessed.

As a result gdb ends up reading uninitialised memory, sometimes this
uninitialised memory indicates the variable is associated (when it's
not).  This first mistake can lead to a cascade of errors, reading
uninitialised memory, with the result that gdb builds an invalid type to
associate with the variable pvla2.

In some cases, this invalid type can be very large, which when we try to
print pvla2 causes gdb to allocate a large amount of memory.

A recent commit added a new gdb variable 'max-value-size', which
prevents gdb from allocating values of extreme size.  As a result
directly trying to print pvla2 will now now error rather than allocate a
large amount of memory.

However, some of the later tests create a varobj for pvla2, and then
ask for the children of that varobj to be displayed.  In the case where
an invalid type has been computed for pvla2 then the number of children
can be wrong, and very big, in which case trying to display all of these
children can cause gdb to consume an excessive amount of memory.

This commit first detects if printing pvla2 triggers the max-value-size
error, if it does then we avoid all the follow on tests relating to the
unassociated pvla2, which avoids the second error printing the varobj
children.

gdb/testsuite/ChangeLog:

* gdb.mi/mi-vla-fortran.exp: Add XFAIL for accessing unassociated
pointer.  Don't perform further tests on the unassociated pointer
if the first test fails.
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.mi/mi-vla-fortran.exp