[Bug fortran/56596] New: Invalid read of size 4 gfortran.dg/class_array_7.f03

[Bug fortran/56596] New: Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596

             Bug #: 56596
           Summary: Invalid read of size 4 gfortran.dg/class_array_7.f03
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr


Running gfortran.dg/class_array_7.f03 under valgrind gives

==54979== Invalid read of size 4
==54979==    at 0x100001731: __realloc_MOD_assign (class_array_7.f03:25)
==54979==    by 0x100001629: __realloc_MOD_reallocate (class_array_7.f03:33)
==54979==    by 0x1000019D8: MAIN__ (class_array_7.f03:55)
==54979==    by 0x100001B7D: main (class_array_7.f03:49)
==54979==  Address 0x10044a408 is 0 bytes after a block of size 40 alloc'd
==54979==    at 0x100013679: malloc (vg_replace_malloc.c:266)
==54979==    by 0x1000017E0: MAIN__ (class_array_7.f03:53)
==54979==    by 0x100001B7D: main (class_array_7.f03:49)
==54979== 
==54979== 
==54979== HEAP SUMMARY:
==54979==     in use at exit: 88 bytes in 1 blocks
==54979==   total heap usage: 25 allocs, 24 frees, 7,061 bytes allocated
==54979== 
==54979== LEAK SUMMARY:
==54979==    definitely lost: 0 bytes in 0 blocks
==54979==    indirectly lost: 0 bytes in 0 blocks
==54979==      possibly lost: 0 bytes in 0 blocks
==54979==    still reachable: 0 bytes in 0 blocks
==54979==         suppressed: 88 bytes in 1 blocks
==54979== 
==54979== For counts of detected and suppressed errors, rerun with: -v
==54979== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 0 from 0)

The test also aborts if it is compiled with -fsanitize=address.

Reduced test

module realloc
  implicit none

  type :: base_type
     integer :: i
  contains
    procedure :: assign
    generic :: assignment(=) => assign   ! define generic assignment
  end type base_type

  type, extends(base_type) :: extended_type
     integer :: j
  end type extended_type

contains

  elemental subroutine assign (a, b)
    class(base_type), intent(out) :: a
    class(base_type), intent(in) :: b
    a%i = b%i
  end subroutine assign

  subroutine reallocate (a)
    class(extended_type), dimension(:), allocatable :: tmp
    class(base_type), dimension(:), allocatable, intent(inout) :: a
    allocate (extended_type :: tmp (size (a))) ! how to alloc b with same type
as a ?
    tmp = a             ! polymorphic l.h.s.
    call move_alloc (from=tmp, to=a)
  end subroutine reallocate

end module realloc

program main
  use realloc
  implicit none
  class(base_type), dimension(:), allocatable :: a

  allocate (extended_type :: a(10))
  call reallocate (a)
end program main

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org 2013-03-13 14:17:40 UTC ---
Reduced test case:


program main
  implicit none

  type :: base_type
    integer :: i
  end type

  type, extends(base_type) :: extended_type
    integer :: j
  end type

  class(base_type), dimension(:), allocatable :: a
  type(extended_type), dimension(1:2) :: tmp

  allocate (extended_type :: a(2))

  tmp%i=a%i
end


I think the problem is in the allocate statement:

a._data.data = (void * restrict) __builtin_malloc (8);

The allocation size seems to be independent of whether one allocates with
"base_type" or "extended type".

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-06-27
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I no longer see the valgrind error at revision 200078 (clean tree). Can this be
confirmed?

On my working tree (r200429, several patches) using valgrind with
--leak-check=full gives

==85435== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2
==85435==    at 0x100013679: malloc (vg_replace_malloc.c:266)
==85435==    by 0x100001358: __realloc_MOD_reallocate (class_array_7.f03:31)
==85435==    by 0x1000019C6: MAIN__ (class_array_7.f03:55)
==85435==    by 0x100001B5B: main (class_array_7.f03:49)

(no error without --leak-check=full). Investigating.

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This seems to have been fixed between revision 199435 (2013-05-30) and revision
199885 (2013-06-03): revision 199528?

The error

==15298== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2
==15298==    at 0x100013679: malloc (vg_replace_malloc.c:266)
==15298==    by 0x100001358: __realloc_MOD_reallocate (class_array_7.f03:31)
==15298==    by 0x1000019C6: MAIN__ (class_array_7.f03:55)
==15298==    by 0x100001B5B: main (class_array_7.f03:49)

appeared between revisions 200350 (2013-06-23) with the patch of revision
200361 and a clean revision 200361 (2013-06-24). Could it be caused by revision
200360?

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |burnus at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to janus from comment #1)
>   allocate (extended_type :: a(2))
> a._data.data = (void * restrict) __builtin_malloc (8);
> 
> The allocation size seems to be independent of whether one allocates with
> "base_type" or "extended type".

(In reply to Dominique d'Humieres from comment #3)
> This seems to have been fixed [...] revision 199528?

Yes, it has been fixed by the patch for PR57456, r199528

-> Close as FIXED.

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot med.uc.edu

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 55482 has been marked as a duplicate of this bug. ***

[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I have opened pr57762 for the memory leak reported in comments #2 and #3 (with
the right bracketing this time).