| Summary: | [OOP] Memory leak with allocatable polymorphics | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Rich Townsend <townsend> |
| Component: | fortran | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | burnus, janus |
| Priority: | P3 | ||
| Version: | 4.9.0 | ||
| Target Milestone: | 4.9.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
| Attachments: | Example program | ||
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) (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. (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. |
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.