Bug 57922 - [OOP] Memory leak with allocatable polymorphics
Summary: [OOP] Memory leak with allocatable polymorphics
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: 4.9.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-17 23:19 UTC by Rich Townsend
Modified: 2016-11-16 17:38 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Example program (227 bytes, text/x-fortran)
2013-07-17 23:19 UTC, Rich Townsend
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Townsend 2013-07-17 23:19:40 UTC
Created attachment 30520 [details]
Example program

I'm experiencing a problem with:

Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130404 (experimental) (GCC) 

The attached example program demonstrates the problem. When f is deallocated, it seems that f%x is not getting deallocated, causing the memory footprint of the program (as reported by the ps syscall) to grow without bound.
Comment 1 janus 2013-07-20 07:14:35 UTC
On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8. However, the leak seems to be gone in the latest trunk version:

gcc version 4.9.0 20130718 (experimental) [trunk revision 201038] (GCC)
Comment 2 Tobias Burnus 2013-07-20 20:24:43 UTC
(In reply to janus from comment #1)
> On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8.
> However, the leak seems to be gone in the latest trunk version:

Which is not very surprising as the finalization code should also take care of this. See PR37336. I believe r199643 was the enabling commit.
Comment 3 janus 2013-07-22 07:24:45 UTC
(In reply to Tobias Burnus from comment #2)
> (In reply to janus from comment #1)
> > On x86_64-unknown-linux-gnu, I can confirm the problem with 4.7 and 4.8.
> > However, the leak seems to be gone in the latest trunk version:
> 
> Which is not very surprising as the finalization code should also take care
> of this. See PR37336. I believe r199643 was the enabling commit.

Right. Although the test case does not actually deal with finalization, but rather involves polymorphic deallocation (i.e. PR 46321).

Anyway, closing as fixed.