[Bug fortran/114827] New: Valgrind reports errors with class(*) assignment

[Bug fortran/114827] New: Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com]

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

            Bug ID: 114827
           Summary: Valgrind reports errors with class(*) assignment
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

I'm trying to pin down a malloc corruption error ("malloc(): corrupted top
size") that happens during finalization of a derived type object. I'm still
working on paring things down to a reportable reproducer, but the traceback
hinted at a possible problem with the assignment of a class(*) variable to
another allocatable class(*) variable when the dynamic type of the rhs is
character. I've turned that bit into the following example which compiles and
runs without error, but when run under valgrind it reports several invalid
writes, which suggests to me that the executable is doing something wrong.

Note that if the assignment to the allocatable class(*) variable is replaced by
a sourced-allocation, the valgrind output is completely clean.

$ cat foo.f90
program main
  call run
contains
  subroutine run
    class(*), allocatable :: y
    call foo('fubarfubarfubarfubarfubarfu', y)
  end subroutine 
  subroutine foo(a, b)
    class(*), intent(in) :: a
    class(*), allocatable :: b
    b = a
    !allocate(b, source=a) ! VALGRIND REPORTS NO INVALID WRITES 
  end subroutine
end program

$ gfortran -g -O0 foo.f90

$ valgrind -s ./a.out
==587107== Memcheck, a memory error detector
==587107== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==587107== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==587107== Command: ./a.out
==587107== 
==587107== Invalid write of size 2
==587107==    at 0x484F353: memmove (vg_replace_strmem.c:1410)
==587107==    by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==    by 0x401368: foo.1 (foo.f90:11)
==587107==    by 0x4013E1: run.2 (foo.f90:6)
==587107==    by 0x401258: MAIN__ (foo.f90:2)
==587107==    by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ac0 is 0 bytes inside a block of size 1 alloc'd
==587107==    at 0x484280F: malloc (vg_replace_malloc.c:442)
==587107==    by 0x4012C2: foo.1 (foo.f90:11)
==587107==    by 0x4013E1: run.2 (foo.f90:6)
==587107==    by 0x401258: MAIN__ (foo.f90:2)
==587107==    by 0x401485: main (foo.f90:2)
==587107== 
==587107== Invalid write of size 1
==587107==    at 0x484F383: memmove (vg_replace_strmem.c:1410)
==587107==    by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==    by 0x401368: foo.1 (foo.f90:11)
==587107==    by 0x4013E1: run.2 (foo.f90:6)
==587107==    by 0x401258: MAIN__ (foo.f90:2)
==587107==    by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ada is 10 bytes after a block of size 16 in arena
"client"
==587107== 
==587107== 
==587107== HEAP SUMMARY:
==587107==     in use at exit: 0 bytes in 0 blocks
==587107==   total heap usage: 22 allocs, 22 frees, 13,585 bytes allocated
==587107== 
==587107== All heap blocks were freed -- no leaks are possible
==587107== 
==587107== ERROR SUMMARY: 27 errors from 2 contexts (suppressed: 0 from 0)
==587107== 
==587107== 1 errors in context 1 of 2:
==587107== Invalid write of size 1
==587107==    at 0x484F383: memmove (vg_replace_strmem.c:1410)
==587107==    by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==    by 0x401368: foo.1 (foo.f90:11)
==587107==    by 0x4013E1: run.2 (foo.f90:6)
==587107==    by 0x401258: MAIN__ (foo.f90:2)
==587107==    by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ada is 10 bytes after a block of size 16 in arena
"client"
==587107== 
==587107== 
==587107== 26 errors in context 2 of 2:
==587107== Invalid write of size 2
==587107==    at 0x484F353: memmove (vg_replace_strmem.c:1410)
==587107==    by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==    by 0x401368: foo.1 (foo.f90:11)
==587107==    by 0x4013E1: run.2 (foo.f90:6)
==587107==    by 0x401258: MAIN__ (foo.f90:2)
==587107==    by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ac0 is 0 bytes inside a block of size 1 alloc'd
==587107==    at 0x484280F: malloc (vg_replace_malloc.c:442)
==587107==    by 0x4012C2: foo.1 (foo.f90:11)
==587107==    by 0x4013E1: run.2 (foo.f90:6)
==587107==    by 0x401258: MAIN__ (foo.f90:2)
==587107==    by 0x401485: main (foo.f90:2)
==587107== 
==587107== ERROR SUMMARY: 27 errors from 2 contexts (suppressed: 0 from 0)

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #1 from Neil Carlson <neil.n.carlson at gmail dot com> ---
I should add that I get the same results with gcc versions going back to at
least gcc 11.

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Have you tried configuring gcc with --enable-valgrind-annotations and see what
results this gives?

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #3 from Neil Carlson <neil.n.carlson at gmail dot com> ---
Those results are with 12.3.0 configured with --enable-valgrind-annotations.
I'm building 13.2.0 now with the same to see if more info is generated. (I
don't typically use 13.x because it finalization is broken for our code after
12.)

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #4 from Neil Carlson <neil.n.carlson at gmail dot com> ---
Same results with 13.2.0 configured with --enable-valgrind-annotations.

Here's the output with 13.2.0 and gfortran -g -O0 -fsanitize=address foo.f90 :

==1126830==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x602000000071 at pc 0x7fb97cc6b21d bp 0x7ffcd7a79200 sp 0x7ffcd7a789c0
WRITE of size 27 at 0x602000000071 thread T0
    #0 0x7fb97cc6b21c in __interceptor_memmove
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:882
    #1 0x4012ca in __copy_character_1 /home/nnc/Codes/petaca/bugs/foo.f90:1
    #2 0x401a14 in foo /home/nnc/Codes/petaca/bugs/foo.f90:11
    #3 0x401cf9 in run /home/nnc/Codes/petaca/bugs/foo.f90:6
    #4 0x401374 in MAIN__ /home/nnc/Codes/petaca/bugs/foo.f90:2
    #5 0x401fc6 in main /home/nnc/Codes/petaca/bugs/foo.f90:2
    #6 0x7fb97c646149 in __libc_start_call_main (/lib64/libc.so.6+0x28149)
(BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273)
    #7 0x7fb97c64620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a)
(BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273)
    #8 0x401194 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401194)

0x602000000071 is located 0 bytes after 1-byte region
[0x602000000070,0x602000000071)
allocated by thread T0 here:
    #0 0x7fb97ccdc2ef in __interceptor_malloc
../../../../libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x4017c9 in foo /home/nnc/Codes/petaca/bugs/foo.f90:11
    #2 0x401cf9 in run /home/nnc/Codes/petaca/bugs/foo.f90:6
    #3 0x401374 in MAIN__ /home/nnc/Codes/petaca/bugs/foo.f90:2
    #4 0x401fc6 in main /home/nnc/Codes/petaca/bugs/foo.f90:2
    #5 0x7fb97c646149 in __libc_start_call_main (/lib64/libc.so.6+0x28149)
(BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273)
    #6 0x7fb97c64620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a)
(BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273)
    #7 0x401194 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401194)

SUMMARY: AddressSanitizer: heap-buffer-overflow
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:882
in __interceptor_memmove
Shadow bytes around the buggy address:
  0x601ffffffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601ffffffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601ffffffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601fffffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601fffffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x602000000000: fa fa 06 fa fa fa 07 fa fa fa 07 fa fa fa[01]fa
  0x602000000080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==1126830==ABORTING

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-04-24
           Keywords|                            |wrong-code

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

Two data points which give a hint what might be wrong:

1) the valgrind error count at runtime depends on the string length passed
   to foo.  I get no errors for a string of length 1.

2) the dump-tree of subroutine foo looks suspicious:

    if (b->_data == 0B)
      {
        b->_data = __builtin_malloc (MAX_EXPR <(unsigned long)
rhs.1._vptr->_size, 1>);

It looks like _size comes from:

  static struct __vtype_CHARACTER_1_ __vtab_CHARACTER_1_ = {._hash=85893463,
._size=1, ._extends=0B, ._def_init=0B, ._copy=__copy_character_1, ._final=0B};

and is always 1.  On the other hand, subroutine run sets:

        class.2._vptr = (struct __vtype__STAR * {ref-all})
&__vtab_CHARACTER_1_;
        class.2._data = (void *) &"fubarfubarfubarfubarfubarfu"[1]{lb: 1 sz:
1};
        class.2._len = 27;

but _len is used in foo for the _copy, but not for the allocation.

Thus the size allocated needs to be fixed.

Changing the character argument to use kind=4, I see that _size seems to
represent the element size.

The allocation size thus should be changed to (_size * _len).

Need to find the place where this happens...  Anyone?

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #6 from Neil Carlson <neil.n.carlson at gmail dot com> ---
Here's a variation of the example involving arrays. I expect the source of the
failure here is the same, but I want to be sure this example is also fixed by
the eventual patch.

program main
  call run
contains
  subroutine run
    class(*), allocatable :: y(:)
    call foo(['fubar','fubar'], y)
  end subroutine 
  subroutine foo(a, b)
    class(*), intent(in) :: a(:)
    class(*), allocatable :: b(:)
    b = a
    !allocate(b, source=a) ! VALGRIND REPORTS NO INVALID WRITES 
  end subroutine
end program

Compiled with -fsanitize=address and executed gives this:

==1338704==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x602000000072 at pc 0x7fb456a4c8d1 bp 0x7ffcfd375d50 sp 0x7ffcfd375500
WRITE of size 5 at 0x602000000072 thread T0
    #0 0x7fb456a4c8d0 in __interceptor_memmove
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810
    #1 0x4012d4 in __copy_character_1 /home/nnc/Codes/petaca/bugs/fubar.f90:1
    #2 0x401c9f in foo /home/nnc/Codes/petaca/bugs/fubar.f90:11
    #3 0x4023e8 in run /home/nnc/Codes/petaca/bugs/fubar.f90:6
    #4 0x40137e in MAIN__ /home/nnc/Codes/petaca/bugs/fubar.f90:2
    #5 0x4027a1 in main /home/nnc/Codes/petaca/bugs/fubar.f90:2
    #6 0x7fb4563ff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149)
    #7 0x7fb4563ff20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a)
    #8 0x401184 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401184)

0x602000000072 is located 0 bytes to the right of 2-byte region
[0x602000000070,0x602000000072)
allocated by thread T0 here:
    #0 0x7fb456abd69f in __interceptor_malloc
../../../../libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x401965 in foo /home/nnc/Codes/petaca/bugs/fubar.f90:11
    #2 0x4023e8 in run /home/nnc/Codes/petaca/bugs/fubar.f90:6
    #3 0x40137e in MAIN__ /home/nnc/Codes/petaca/bugs/fubar.f90:2
    #4 0x4027a1 in main /home/nnc/Codes/petaca/bugs/fubar.f90:2
    #5 0x7fb4563ff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149)
    #6 0x7fb4563ff20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a)
    #7 0x401184 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401184)

SUMMARY: AddressSanitizer: heap-buffer-overflow
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810
in __interceptor_memmove

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 58048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58048&action=edit
Partial patch

This patch fixes the scalar case in comment#0 by computing _size*_len
and regtests cleanly.  It does not cover the array case.

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 58056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58056&action=edit
Patch part 2.

This part fixes the array case.  Needs further testing.

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #58048|0                           |1
        is obsolete|                            |
  Attachment #58056|0                           |1
        is obsolete|                            |
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org

--- Comment #9 from anlauf at gcc dot gnu.org ---
Created attachment 58061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58061&action=edit
Corrected patch

This fixes the issue for scalar and array assignments and does not regress
on intrinsic types when compiling with -fsanitize=address.

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #10 from Neil Carlson <neil.n.carlson at gmail dot com> ---
Thanks Harald for hunting this down!

I've tested your patch on master with -fsanitize=address against my library
that turned up these errors and it all looks good now. Is it possible to back
port this to the 12 branch?

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-April/060464.html