[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 --- Comment #12 from Paul Thomas --- (In reply to Tobias Burnus from comment #11) > Related / same issue: > https://gcc.gnu.org/pipermail/fortran/2021-January/055654.html Hi Tobias, Over the weekend, I had a stab at fixing this recent issue. I can fix this but at the risk of increasing the problem of leaks in the original examples in this PR and causing some regressions. I am going to make the testcase for PR98342 leak free so that the the specific problems are separated. Cheers Paul
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus --- Related / same issue: https://gcc.gnu.org/pipermail/fortran/2021-January/055654.html
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 --- Comment #10 from Paul Thomas --- Of the testcases originally highlighted: alloc_comp_assign_2.f90 still leaks alloc_comp_assign_4.f90 still leaks alloc_comp_basics_2.f90 still leaks alloc_comp_basics_5.f90 is OK - probably always was! alloc_comp_constructor_2.f90 still leaks alloc_comp_initializer_1.f90 still leaks alloc_comp_constructor_2.f90 also leaks It's time to deal with this! Paul
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 --- Comment #9 from Paul Thomas --- class_array_15.f03 leaks from line 65-66: allocate (indv(2), source = [individual(1, [99,999]), & individual(2, [999,])]) ==22496== HEAP SUMMARY: ==22496== in use at exit: 32 bytes in 4 blocks ==22496== total heap usage: 31 allocs, 27 frees, 12,096 bytes allocated ==22496== ==22496== 8 bytes in 1 blocks are definitely lost in loss record 1 of 3 ==22496==at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==22496==by 0x403582: pr53876_ (class_array_15.f03:66) ==22496==by 0x403D83: MAIN__ (class_array_15.f03:53) ==22496==by 0x403DC4: main (class_array_15.f03:56) ==22496== ==22496== 8 bytes in 1 blocks are definitely lost in loss record 2 of 3 ==22496==at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==22496==by 0x40375C: pr53876_ (class_array_15.f03:66) ==22496==by 0x403D83: MAIN__ (class_array_15.f03:53) ==22496==by 0x403DC4: main (class_array_15.f03:56) ==22496== ==22496== 16 bytes in 2 blocks are definitely lost in loss record 3 of 3 ==22496==at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==22496==by 0x4039AE: pr53876_ (class_array_15.f03:66) ==22496==by 0x403D83: MAIN__ (class_array_15.f03:53) ==22496==by 0x403DC4: main (class_array_15.f03:56) ==22496== ==22496== LEAK SUMMARY: ==22496==definitely lost: 32 bytes in 4 blocks ==22496==indirectly lost: 0 bytes in 0 blocks ==22496== possibly lost: 0 bytes in 0 blocks ==22496==still reachable: 0 bytes in 0 blocks ==22496== suppressed: 0 bytes in 0 blocks ==22496== ==22496== For counts of detected and suppressed errors, rerun with: -v ==22496== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 2) The coming patch for PR78293 halves this number. The remaining leaks are associated with the temporaries associated with individual(1, [99,999]), where the component 'genes' does not get deallocated. Paul
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Paul Thomas from comment #0) alloc_comp_assign_4.f90 nested constructors(line 56) With current trunk I see additional leaks in lines 28 and 29. Those are again due to not auto-deallocating variables in the main program, which is an F08 feature, not a gfortran bug. The leak in line 56 persists. Here is a reduced test case for that: type :: a character(4), allocatable :: ch(:) end type a call test_ab6 () contains subroutine test_ab6 () type b type(a) :: a end type b type c type(b), allocatable :: b(:) end type c type(c):: p p = c((/b(a((/Mary,Lamb/)))/)) end subroutine end While 4.4 shows only a single 8-byte leak, 4.6 to trunk shows two of them.
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #7 from janus at gcc dot gnu.org --- I think it is indeed expected for valgrind to report leaks for the code in comment 5, since variables in the main program are not supposed to be auto-deallocated in F08. Valgrind does not show any leaks if I put x into a subroutine: type :: thytype integer(4), allocatable :: h(:) end type thytype type :: mytype type(thytype), allocatable :: q(:) end type mytype contains subroutine s type (mytype) :: x x = mytype ([thytype([555])]) end subroutine end One should check the test cases listed in comment 0, in order to see if they still show leaks and if those are actual bugs.
[Bug fortran/38319] Memory leaks in allocatable component expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 xiaoyuanbo xiaoyuanbo at yeah dot net changed: What|Removed |Added CC||xiaoyuanbo at yeah dot net --- Comment #6 from xiaoyuanbo xiaoyuanbo at yeah dot net 2012-02-22 12:54:34 UTC --- you know that title
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-02-25 12:50 --- Subject: Re: Memory leaks in allocatable component expressions --- Comment #3 from burnus at gcc dot gnu dot org 2010-02-25 07:38 --- Paul, can you try with valgrind --leak-check=full ? Without the =full option, I also do not get any line info output but just in the summary definitely lost: 288 bytes in 4 blocks. Tobias, I cannot remember how valgrind puts it but I get the no memory leaks possible message, even with =full. Cheers Possible -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-25 13:54 --- type :: thytype integer(4), allocatable :: h(:) end type thytype type :: mytype type(thytype), allocatable :: q(:) end type mytype type (mytype) :: x x = mytype ([thytype([555])]) end Reduced test case. If I read the dump correctly, one effectively does: tmp = thytype([555]) x = mytype(tmp) however, for mytype(tmp) the data is copied instead of simply assigning the pointer tmp.data and tmp.data is never freed. a) One creates thytype with the value 555: (*(struct thytype[1] * restrict) atmp.1.data)[0] = thytype.4; - and recopying again: (*(struct thytype[1] * restrict) atmp.7.data)[S.9] = (*(struct thytype[1] * restrict) atmp.1.data)[S.9]; b) One now assigns that data to mytype - but not directly but via malloc+memcopy: D.1592 = (void * restrict) __builtin_malloc (MAX_EXPR D.1591, 1); (*(struct thytype[0:] * restrict) mytype.0.q.data)[S.10].h.data = D.1592; __builtin_memcpy ((integer(kind=4)[0:] * restrict) (*(struct thytype[0:] * restrict) mytype.0.q.data)[S.10].h.data, (integer(kind=4)[0:] * restrict) (*(struct thytype[1] * restrict) atmp.7.data)[S.10].h.data, D.1590 * 4); The problem is now that atmp.7.data.h.data is never freed. It would be fantastic if instead of freeing atmp.7.data.h.data one could simply assign atmp.7.data.h.data to mytype.0.q.data[S.10].h.data without malloc/memcpy. I am sure it is nontrivial, but I would really like to see the number of temporaries be cut down. The dumps are pretty hard to read and we probably give also the middle end a hard time in figuring out that we do not need ~8 mallocs but one three - especially since the middle end does not really optimize malloc/free (it could, but it doesn't - yet). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- Comment #2 from pault at gcc dot gnu dot org 2010-02-24 20:31 --- I have been having trouble in recent times detecting these memory leaks. Neither FC9 nor RHEL5.2 x86_64 seem to show them with valgrind. Since I know that others still see them, I wonder are there any ideas what I have to do to detect them? It´s a tad difficult to fix the memory leaks if I cannot detect them :-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-25 07:38 --- Paul, can you try with valgrind --leak-check=full ? Without the =full option, I also do not get any line info output but just in the summary definitely lost: 288 bytes in 4 blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-30 19:07 --- See also http://gcc.gnu.org/ml/fortran/2009-07/msg00260.html and PR 40899. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/38319] Memory leaks in allocatable component expressions
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-29 21:54:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
