[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.4 --- Comment #16 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #14) > Backporting to 13-branch requires backporting of r14-5931-gb247e917ff1332, > see pr110415. After a successful backport of the above, the present patch also applied smoothly to 13-branch. Closing. Thanks for the report!
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #15 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f0b88ec4ae829798cb533618f781ca467bab6b9b commit r13-8794-gf0b88ec4ae829798cb533618f781ca467bab6b9b Author: Harald Anlauf Date: Mon Apr 29 19:52:52 2024 +0200 Fortran: fix issues with class(*) assignment [PR114827] gcc/fortran/ChangeLog: PR fortran/114827 * trans-array.cc (gfc_alloc_allocatable_for_assignment): Take into account _len of unlimited polymorphic entities when calculating the effective element size for allocation size and array span. Set _len of lhs to _len of rhs. * trans-expr.cc (trans_class_assignment): Take into account _len of unlimited polymorphic entities for allocation size. gcc/testsuite/ChangeLog: PR fortran/114827 * gfortran.dg/asan/unlimited_polymorphic_34.f90: New test. (cherry picked from commit 21e7aa5f3ea44ca2fef8deb8788edffc04901b5c)
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #14 from anlauf at gcc dot gnu.org --- Backporting to 13-branch requires backporting of r14-5931-gb247e917ff1332, see pr110415.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #13 from GCC Commits --- The releases/gcc-14 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a5046235509caa10a4dc309ca0a8e67892b27750 commit r14-10191-ga5046235509caa10a4dc309ca0a8e67892b27750 Author: Harald Anlauf Date: Mon Apr 29 19:52:52 2024 +0200 Fortran: fix issues with class(*) assignment [PR114827] gcc/fortran/ChangeLog: PR fortran/114827 * trans-array.cc (gfc_alloc_allocatable_for_assignment): Take into account _len of unlimited polymorphic entities when calculating the effective element size for allocation size and array span. Set _len of lhs to _len of rhs. * trans-expr.cc (trans_class_assignment): Take into account _len of unlimited polymorphic entities for allocation size. gcc/testsuite/ChangeLog: PR fortran/114827 * gfortran.dg/asan/unlimited_polymorphic_34.f90: New test. (cherry picked from commit 21e7aa5f3ea44ca2fef8deb8788edffc04901b5c)
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #12 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:21e7aa5f3ea44ca2fef8deb8788edffc04901b5c commit r15-168-g21e7aa5f3ea44ca2fef8deb8788edffc04901b5c Author: Harald Anlauf Date: Mon Apr 29 19:52:52 2024 +0200 Fortran: fix issues with class(*) assignment [PR114827] gcc/fortran/ChangeLog: PR fortran/114827 * trans-array.cc (gfc_alloc_allocatable_for_assignment): Take into account _len of unlimited polymorphic entities when calculating the effective element size for allocation size and array span. Set _len of lhs to _len of rhs. * trans-expr.cc (trans_class_assignment): Take into account _len of unlimited polymorphic entities for allocation size. gcc/testsuite/ChangeLog: PR fortran/114827 * gfortran.dg/asan/unlimited_polymorphic_34.f90: New test.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
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
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #10 from Neil Carlson --- 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
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=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
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=edit Patch part 2. This part fixes the array case. Needs further testing.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #6 from Neil Carlson --- 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 0x60200072 at pc 0x7fb456a4c8d1 bp 0x7ffcfd375d50 sp 0x7ffcfd375500 WRITE of size 5 at 0x60200072 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) 0x60200072 is located 0 bytes to the right of 2-byte region [0x60200070,0x60200072) 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #4 from Neil Carlson --- 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 0x60200071 at pc 0x7fb97cc6b21d bp 0x7ffcd7a79200 sp 0x7ffcd7a789c0 WRITE of size 27 at 0x60200071 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) 0x60200071 is located 0 bytes after 1-byte region [0x60200070,0x60200071) 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: 0x601ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601ffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x6020: fa fa 06 fa fa fa 07 fa fa fa 07 fa fa fa[01]fa 0x60200080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200280: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #3 from Neil Carlson --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- Have you tried configuring gcc with --enable-valgrind-annotations and see what results this gives?
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #1 from Neil Carlson --- I should add that I get the same results with gcc versions going back to at least gcc 11.
