[Bug gdb/27059] New: gdb.fortran/vla-type.exp fails when GDB is built with ASan

[Bug gdb/27059] New: gdb.fortran/vla-type.exp fails when GDB is built with ASan

[simark at simark dot ca]

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

            Bug ID: 27059
           Summary: gdb.fortran/vla-type.exp fails when GDB is built with
                    ASan
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: simark at simark dot ca
  Target Milestone: ---

Since 5bbd8269fa8d ("gdb/fortran: array stride support"), the test
gdb.fortran/vla-type.exp fails when GDB is built with AddressSanitizer.

This is the failure:

ptype fivedynarr(2)                                                             
/home/simark/src/binutils-gdb/gdb/valarith.c:1390:10: runtime error: signed
integer overflow: 3573412791104 * 140737350904416 cannot be represented in type
'long int'

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

[Bug gdb/27059] gdb.fortran/vla-type.exp fails when GDB is built with ASan

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.1

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

[Bug gdb/27059] gdb.fortran/vla-type.exp fails when GDB is built with ASan

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b7874836c331d13e5478c775477b12abf7c481a0

commit b7874836c331d13e5478c775477b12abf7c481a0
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Fri Dec 18 11:59:54 2020 +0000

    gdb: avoid resolving dynamic properties for non-allocated arrays

    In PR gdb/27059 an issue was discovered where GDB would sometimes
    trigger undefined behaviour in the form of signed integer overflow.
    The problem here is that GDB was reading random garbage from the
    inferior memory space, assuming this data was valid, and performing
    arithmetic on it.

    This bug raises an interesting general problem with GDB's DWARF
    expression evaluator, which is this:

    We currently assume that the DWARF expressions being evaluated are
    well formed, and well behaving.  As an example, this is the expression
    that the bug was running into problems on, this was used as the
    expression for a DW_AT_byte_stride of a DW_TAG_subrange_type:

            DW_OP_push_object_address;
            DW_OP_plus_uconst: 88;
            DW_OP_deref;
            DW_OP_push_object_address;
            DW_OP_plus_uconst: 32;
            DW_OP_deref;
            DW_OP_mul

    Two values are read from the inferior and multiplied together.  GDB
    should not assume that any value read from the inferior is in any way
    sane, as such the implementation of DW_OP_mul should be guarding
    against overflow and doing something semi-sane here.

    However, it turns out that the original bug PR gdb/27059, is hitting a
    more specific case, which doesn't require changes to the DWARF
    expression evaluator, so I'm going to leave the above issue for
    another day.

    In the test mentioned in the bug GDB is actually trying to resolve the
    dynamic type of a Fortran array that is NOT allocated.  A
    non-allocated Fortran array is one that does not have any data
    allocated for it yet, and even the upper and lower bounds of the array
    are not yet known.

    It turns out that, at least for gfortran compiled code, the data
    fields that describe the byte-stride are not initialised until the
    array is allocated.

    This leads me to the following conclusion: GDB should not try to
    resolve the bounds, or stride information for an array that is not
    allocated (or not associated, a similar, but slightly different
    Fortran feature).  Instead, each of these properties should be set to
    undefined if the array is not allocated (or associated).

    That is what this commit does.  There's a new flag that is passed
    around during the dynamic array resolution.  When this flag is true
    the dynamic properties are resolved using the DWARF expressions as
    they currently are, but when this flag is false the expressions are
    not evaluated, and instead the properties are set to undefined.

    gdb/ChangeLog:

            PR gdb/27059
            * eval.c (evaluate_subexp_for_sizeof): Handle not allocated and
            not associated arrays.
            * f-lang.c (fortran_adjust_dynamic_array_base_address_hack): Don't
            adjust arrays that are not allocated/associated.
            * gdbtypes.c (resolve_dynamic_range): Update header comment.  Add
            new parameter which is used to sometimes set dynamic properties to
            undefined.
            (resolve_dynamic_array_or_string): Update header comment.  Add new
            parameter which is used to guard evaluating dynamic properties.
            Resolve allocated/associated properties first.

    gdb/testsuite/ChangeLog:

            PR gdb/27059
            * gdb.dwarf2/dyn-type-unallocated.c: New file.
            * gdb.dwarf2/dyn-type-unallocated.exp: New file.

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

[Bug gdb/27059] gdb.fortran/vla-type.exp fails when GDB is built with ASan

[andrew.burgess at embecosm dot com]

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

Andrew Burgess <andrew.burgess at embecosm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |andrew.burgess at embecosm dot com

--- Comment #2 from Andrew Burgess <andrew.burgess at embecosm dot com> ---
This issue should now be resolved.

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