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)

             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: link
Be 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).