[Bug fortran/98263] New: valgrind error in gfc_find_derived_vtab

[Bug fortran/98263] New: valgrind error in gfc_find_derived_vtab

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263

            Bug ID: 98263
           Summary: valgrind error in gfc_find_derived_vtab
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Following on from bug # 9337:

I made a valgrind version of gcc fortran. 

gfortran -v says

gcc version 11.0.0 20201210 (experimental) (97b56dece7413839)

I then compiled as follows:

$ /home/dcb/gcc/./results.20201211.valgrind/bin/gfortran -c
./gfortran.dg/pr93337.f90
==14689== Invalid read of size 1
==14689==    at 0x650C4B: gfc_find_derived_vtab(gfc_symbol*) (class.c:2271)
==14689==    by 0x6B7171: gfc_match_assignment() (match.c:1393)
==14689==    by 0x6E9E52: match_word (parse.c:65)
==14689==    by 0x6E9E52: decode_statement() (parse.c:361)

[Bug fortran/98263] valgrind error in gfc_find_derived_vtab

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
bug 9337 => 93337

[Bug fortran/98263] valgrind error in gfc_find_derived_vtab

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-12-13

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

A slightly modified version of pr93337.f90 suggests that the invalid read
happens when dealing with the assignment:

program p
  type t
     character(:), allocatable :: a
  end type t
  class(t), allocatable :: y
  class(t)              :: x
  y = x
end

Swapping x and y in the assignment makes the invalid read disappear.
Either the parsing or resolution of the assignment causes the issue,
or there is corruption during error recovery.

Apparently the fix for PR93337 uncovered this (latent) issue.

[Bug fortran/98263] valgrind error in gfc_find_derived_vtab

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |89891

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
An instrumented compiler gives

==70881==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000000eee
at pc 0x00010007eafc bp 0x7ffeefbfe430 sp 0x7ffeefbfe428
READ of size 1 at 0x604000000eee thread T0
    #0 0x10007eafb in gfc_find_derived_vtab(gfc_symbol*) class.c:2271
    #1 0x1000a1555 in gfc_find_vtab(gfc_typespec*) class.c:2910
    #2 0x100263a54 in gfc_match_assignment() match.c:1393
    #3 0x100367bd1 in match_word(char const*, match (*)(), locus*) parse.c:65
    #4 0x10037530c in decode_statement() parse.c:361
    #5 0x100377a2c in next_free() parse.c:1316
    #6 0x1003784e8 in next_statement() parse.c:1548
    #7 0x10037ecd7 in parse_spec(gfc_statement) parse.c:3967
    #8 0x100385b26 in parse_progunit(gfc_statement) parse.c:5896
    #9 0x1003882e6 in gfc_parse_file() parse.c:6437
    #10 0x100571b05 in gfc_be_parse_file() f95-lang.c:212
    #11 0x1075172c7 in compile_file() toplev.c:457
    #12 0x107525744 in do_compile() toplev.c:2193
    #13 0x10bafef19 in toplev::main(int, char**) toplev.c:2332
    #14 0x10c34222c in main main.c:39
    #15 0x7fff20348630 in start+0x0 (libdyld.dylib:x86_64+0x15630)

0x604000000eee is located 30 bytes inside of 48-byte region
[0x604000000ed0,0x604000000f00)
freed by thread T0 here:
    #0 0x15ea1fff7 in wrap_free.part.0 sanitizer_malloc_mac.inc:147
    #1 0x10051cdaa in gfc_delete_symtree(gfc_symtree**, char const*)
symbol.c:2964
    #2 0x100536e2b in gfc_restore_last_undo_checkpoint() symbol.c:3706
    #3 0x100537096 in gfc_undo_symbols() symbol.c:3739
    #4 0x100367afa in reject_statement() parse.c:2678
    #5 0x100367c40 in match_word(char const*, match (*)(), locus*) parse.c:70
    #6 0x10037530c in decode_statement() parse.c:361
    #7 0x100377a2c in next_free() parse.c:1316
    #8 0x1003784e8 in next_statement() parse.c:1548
    #9 0x10037d63b in parse_derived() parse.c:3387
    #10 0x10037f257 in parse_spec(gfc_statement) parse.c:3927
    #11 0x100385b26 in parse_progunit(gfc_statement) parse.c:5896
    #12 0x1003882e6 in gfc_parse_file() parse.c:6437
    #13 0x100571b05 in gfc_be_parse_file() f95-lang.c:212
    #14 0x1075172c7 in compile_file() toplev.c:457
    #15 0x107525744 in do_compile() toplev.c:2193
    #16 0x10bafef19 in toplev::main(int, char**) toplev.c:2332
    #17 0x10c34222c in main main.c:39
    #18 0x7fff20348630 in start+0x0 (libdyld.dylib:x86_64+0x15630)

previously allocated by thread T0 here:
    #0 0x15ea206ff in wrap_calloc sanitizer_malloc_mac.inc:158
    #1 0x10a86d2e5 in xcalloc xmalloc.c:162
    #2 0x10051ca55 in gfc_new_symtree(gfc_symtree**, char const*) symbol.c:2932
    #3 0x10052070e in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3384
    #4 0x10052ca29 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
symbol.c:3469
    #5 0x100259278 in gfc_match_sym_tree(gfc_symtree**, int) match.c:706
    #6 0x1003a71e8 in match_variable(gfc_expr**, int, int) primary.c:3955
    #7 0x1003b57b2 in gfc_match_variable(gfc_expr**, int) primary.c:4099
    #8 0x10025ba6f in gfc_match(char const*, ...) match.c:1162
    #9 0x10026328a in gfc_match_assignment() match.c:1340
    #10 0x100367bd1 in match_word(char const*, match (*)(), locus*) parse.c:65
    #11 0x10037530c in decode_statement() parse.c:361
    #12 0x100377a2c in next_free() parse.c:1316
    #13 0x1003784e8 in next_statement() parse.c:1548
    #14 0x10037d63b in parse_derived() parse.c:3387
    #15 0x10037f257 in parse_spec(gfc_statement) parse.c:3927
    #16 0x100385b26 in parse_progunit(gfc_statement) parse.c:5896
    #17 0x1003882e6 in gfc_parse_file() parse.c:6437
    #18 0x100571b05 in gfc_be_parse_file() f95-lang.c:212
    #19 0x1075172c7 in compile_file() toplev.c:457
    #20 0x107525744 in do_compile() toplev.c:2193
    #21 0x10bafef19 in toplev::main(int, char**) toplev.c:2332
    #22 0x10c34222c in main main.c:39
    #23 0x7fff20348630 in start+0x0 (libdyld.dylib:x86_64+0x15630)

SUMMARY: AddressSanitizer: heap-use-after-free class.c:2271 in
gfc_find_derived_vtab(gfc_symbol*)
Shadow bytes around the buggy address:
  0x1c0800000180: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c0800000190: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00
  0x1c08000001a0: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fd
  0x1c08000001b0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c08000001c0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
=>0x1c08000001d0: fa fa 00 00 00 00 00 00 fa fa fd fd fd[fd]fd fd
  0x1c08000001e0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c08000001f0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c0800000200: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x1c0800000210: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
  0x1c0800000220: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==70881==ABORTING


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891
[Bug 89891] [meta-bug] Accessing memory in rejected statements or expressions

[Bug fortran/98263] valgrind error in gfc_find_derived_vtab

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #4 from anlauf at gcc dot gnu.org ---
This is fixed by the patch for PR96381.

*** This bug has been marked as a duplicate of bug 96381 ***