public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/51160] New: Memory leak with abstract type
@ 2011-11-16 14:52 mrestelli at gmail dot com
2011-11-16 16:04 ` [Bug fortran/51160] [OOP] " burnus at gcc dot gnu.org
2013-08-08 15:04 ` janus at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: mrestelli at gmail dot com @ 2011-11-16 14:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51160
Bug #: 51160
Summary: Memory leak with abstract type
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: mrestelli@gmail.com
Hi,
the attached code, which I think is correct, leaks memory.
According to valgrind this happens in subroutine subr, at line
class(et), intent(inout) :: y
Here is the output:
==29006== HEAP SUMMARY:
==29006== in use at exit: 40,000 bytes in 100 blocks
==29006== total heap usage: 223 allocs, 123 frees, 57,583 bytes allocated
==29006==
==29006== 40,000 bytes in 100 blocks are definitely lost in loss record 1 of 1
==29006== at 0x4C26F5D: malloc (vg_replace_malloc.c:263)
==29006== by 0x400A20: __mod2_MOD___copy_mod2_Et (test.f90:38)
==29006== by 0x4008E6: __mod1_MOD_sub (test.f90:24)
==29006== by 0x400D0C: MAIN__ (test.f90:53)
==29006== by 0x400E1E: main (test.f90:46)
==29006==
==29006== LEAK SUMMARY:
==29006== definitely lost: 40,000 bytes in 100 blocks
==29006== indirectly lost: 0 bytes in 0 blocks
==29006== possibly lost: 0 bytes in 0 blocks
==29006== still reachable: 0 bytes in 0 blocks
==29006== suppressed: 0 bytes in 0 blocks
==29006==
The problem becomes more and more severe increasing n.
gfortran --version
GNU Fortran (GCC) 4.7.0 20111116 (experimental)
and I'm compiling with
gfortran -g test.f90 -o prg
module mod1
implicit none
type, abstract :: at
contains
procedure(i_copy), deferred, pass(y) :: copy
end type at
abstract interface
subroutine i_copy(y,x)
import :: at
implicit none
class(at), intent(in) :: x
class(at), intent(inout) :: y
end subroutine i_copy
end interface
contains
subroutine sub(q,p)
class(at), intent(in) :: p
class(at), intent(inout) :: q
class(at), allocatable :: r
allocate(r,source=p)
call r%copy(p)
call q%copy(r)
deallocate(r)
end subroutine sub
end module mod1
module mod2
use mod1
implicit none
type, extends(at) :: et
real, allocatable :: u(:)
contains
procedure, pass(y) :: copy => subr
end type et
contains
subroutine subr(y,x)
class(at), intent(in) :: x
class(et), intent(inout) :: y
select type(x); type is(et)
y%u = x%u
end select
end subroutine subr
end module mod2
program prog
use mod1
use mod2
integer, parameter :: n = 100
type(et) :: a, b
allocate(a%u(n)); a%u = 1.5
allocate(b%u(n))
do i=1,n
call sub(b,a)
enddo
deallocate(a%u,b%u)
end program prog
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/51160] [OOP] Memory leak with abstract type
2011-11-16 14:52 [Bug fortran/51160] New: Memory leak with abstract type mrestelli at gmail dot com
@ 2011-11-16 16:04 ` burnus at gcc dot gnu.org
2013-08-08 15:04 ` janus at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-11-16 16:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51160
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
CC| |burnus at gcc dot gnu.org,
| |janus at gcc dot gnu.org
Summary|Memory leak with abstract |[OOP] Memory leak with
|type |abstract type
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-16 15:41:41 UTC ---
I think your issue has nothing to do with abstract types but rather with
working with polymorphic data ("CLASS").
I think the issue is that "r"'s "u" component in "sub" is not freed at the end,
which would be a duplicate of PR 46321.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/51160] [OOP] Memory leak with abstract type
2011-11-16 14:52 [Bug fortran/51160] New: Memory leak with abstract type mrestelli at gmail dot com
2011-11-16 16:04 ` [Bug fortran/51160] [OOP] " burnus at gcc dot gnu.org
@ 2013-08-08 15:04 ` janus at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-08 15:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51160
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> I think your issue has nothing to do with abstract types but rather with
> working with polymorphic data ("CLASS").
>
> I think the issue is that "r"'s "u" component in "sub" is not freed at the
> end, which would be a duplicate of PR 46321.
Correct. And now that polymorphic deallocation is implemented, also the memory
leak is gone: The dump shows that the _final procedure is called, and also
valgrind reports a clean memory footprint:
==5457== HEAP SUMMARY:
==5457== in use at exit: 0 bytes in 0 blocks
==5457== total heap usage: 423 allocs, 423 frees, 58,341 bytes allocated
==5457==
==5457== All heap blocks were freed -- no leaks are possible
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-08-08 15:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-16 14:52 [Bug fortran/51160] New: Memory leak with abstract type mrestelli at gmail dot com
2011-11-16 16:04 ` [Bug fortran/51160] [OOP] " burnus at gcc dot gnu.org
2013-08-08 15:04 ` janus at gcc dot gnu.org
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).