public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/51175] New: Memory Leak with Transfer intrinsic
@ 2011-11-16 16:52 stefano.borini at ferrara dot linux.it
2011-11-16 17:28 ` [Bug fortran/51175] " burnus at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: stefano.borini at ferrara dot linux.it @ 2011-11-16 16:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51175
Bug #: 51175
Summary: Memory Leak with Transfer intrinsic
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: stefano.borini@ferrara.linux.it
Hello,
I am using gfortran 4.6.2 on MacOSX 10.7.
It appears that this code involving transfer generates a memory leak
module LeakModule
implicit none
contains
subroutine Leaking(stringdata, string)
character(len=1), intent(in) :: stringdata(:)
character(len=*), intent(out) :: string
character(len=1) :: singleChar(1)
!integer :: numChars
!numChars = size(transfer(stringdata,singleChar))
!string = ''
string = transfer(stringdata, string)
!string(numChars+1:) = ' '
end subroutine
subroutine Foo()
character(len=1) :: stringdata(3)
character(len=20) :: outstring
stringdata(1) = 'H'
stringdata(2) = 'i'
stringdata(3) = '!'
call Leaking(stringdata, outstring)
print *, outstring
end subroutine
end module
program test
use LeakModule
call foo()
end
According to the produced assembler, malloc gets called inside the Leaking
routine, but the asm of the caller never issues a free of that allocated
memory. The same happens even if the string is a local variable with specified
len.
The commented code (calculating the size of the data involved) correctly issues
one malloc and one free.
Thanks
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/51175] Memory Leak with Transfer intrinsic
2011-11-16 16:52 [Bug fortran/51175] New: Memory Leak with Transfer intrinsic stefano.borini at ferrara dot linux.it
@ 2011-11-16 17:28 ` burnus at gcc dot gnu.org
2012-02-22 13:11 ` xiaoyuanbo at yeah dot net
2015-08-16 20:37 ` fxcoudert at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-11-16 17:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51175
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-11-16
CC| |burnus at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-16 17:15:31 UTC ---
(In reply to comment #0)
> I am using gfortran 4.6.2 on MacOSX 10.7.
> It appears that this code involving transfer generates a memory leak
Indeed, valgrind shows:
==3168== 20 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3168== at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==3168== by 0x4009BF: __leakmodule_MOD_leaking (test.f90:14)
==3168== by 0x400889: __leakmodule_MOD_foo (test.f90:26)
==3168== by 0x400A5B: MAIN__ (test.f90:34)
==3168== by 0x400A91: main (test.f90:32)
> print *, outstring
Use:
print *, outstring(1:3)
otherwise you access uninitialized memory.
> According to the produced assembler, malloc gets called inside the Leaking
> routine, but the asm of the caller never issues a free of that allocated
> memory.
Easier than studying the assembler: Use -fdump-tree-original (or
-fdump-tree-optimized) which creates a file of the internal representation with
C-like syntax. [Note: The dump does not contain all details.]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/51175] Memory Leak with Transfer intrinsic
2011-11-16 16:52 [Bug fortran/51175] New: Memory Leak with Transfer intrinsic stefano.borini at ferrara dot linux.it
2011-11-16 17:28 ` [Bug fortran/51175] " burnus at gcc dot gnu.org
@ 2012-02-22 13:11 ` xiaoyuanbo at yeah dot net
2015-08-16 20:37 ` fxcoudert at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: xiaoyuanbo at yeah dot net @ 2012-02-22 13:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51175
xiaoyuanbo <xiaoyuanbo at yeah dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xiaoyuanbo at yeah dot net
--- Comment #2 from xiaoyuanbo <xiaoyuanbo at yeah dot net> 2012-02-22 12:46:16 UTC ---
set char two privilage
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/51175] Memory Leak with Transfer intrinsic
2011-11-16 16:52 [Bug fortran/51175] New: Memory Leak with Transfer intrinsic stefano.borini at ferrara dot linux.it
2011-11-16 17:28 ` [Bug fortran/51175] " burnus at gcc dot gnu.org
2012-02-22 13:11 ` xiaoyuanbo at yeah dot net
@ 2015-08-16 20:37 ` fxcoudert at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-16 20:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51175
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |fxcoudert at gcc dot gnu.org
Resolution|--- |FIXED
Target Milestone|--- |4.7.0
--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
This was fixed in 4.7 and later.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-08-16 20:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-16 16:52 [Bug fortran/51175] New: Memory Leak with Transfer intrinsic stefano.borini at ferrara dot linux.it
2011-11-16 17:28 ` [Bug fortran/51175] " burnus at gcc dot gnu.org
2012-02-22 13:11 ` xiaoyuanbo at yeah dot net
2015-08-16 20:37 ` fxcoudert 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).