public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "neil.n.carlson at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/114827] New: Valgrind reports errors with class(*) assignment Date: Tue, 23 Apr 2024 17:22:57 +0000 [thread overview] Message-ID: <bug-114827-4@http.gcc.gnu.org/bugzilla/> (raw) 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)
next reply other threads:[~2024-04-23 17:22 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-23 17:22 neil.n.carlson at gmail dot com [this message] 2024-04-23 17:24 ` [Bug fortran/114827] " neil.n.carlson at gmail dot com 2024-04-24 3:16 ` jvdelisle at gcc dot gnu.org 2024-04-24 13:19 ` neil.n.carlson at gmail dot com 2024-04-24 15:07 ` neil.n.carlson at gmail dot com 2024-04-24 19:47 ` anlauf at gcc dot gnu.org 2024-04-25 18:43 ` neil.n.carlson at gmail dot com 2024-04-26 19:33 ` anlauf at gcc dot gnu.org 2024-04-27 19:44 ` anlauf at gcc dot gnu.org 2024-04-28 20:37 ` anlauf at gcc dot gnu.org 2024-04-28 22:37 ` neil.n.carlson at gmail dot com 2024-04-29 18:39 ` anlauf at gcc dot gnu.org 2024-05-05 18:35 ` cvs-commit at gcc dot gnu.org 2024-05-09 18:30 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114827-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).