public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/108925] New: memory leak of gfc_get_namespace result
@ 2023-02-24 12:32 rguenth at gcc dot gnu.org
2023-03-06 19:23 ` [Bug fortran/108925] " mikael at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-02-24 12:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
Bug ID: 108925
Summary: memory leak of gfc_get_namespace result
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
valgrind leak check complains
==8747== 3,976 (2,792 direct, 1,184 indirect) bytes in 1 blocks are definitely
lost in loss record 2,248 of 2,309
==8747== at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8747== by 0x1C25680: xcalloc (xmalloc.c:164)
==8747== by 0x7C998E: gfc_get_namespace(gfc_namespace*, int)
(symbol.cc:2869)
==8747== by 0x767D44: load_needed(pointer_info*) (module.cc:5175)
==8747== by 0x767BB5: load_needed(pointer_info*) (module.cc:5153)
==8747== by 0x767BB5: load_needed(pointer_info*) (module.cc:5153)
==8747== by 0x767BB5: load_needed(pointer_info*) (module.cc:5153)
==8747== by 0x767BB5: load_needed(pointer_info*) (module.cc:5153)
==8747== by 0x767BC0: load_needed(pointer_info*) (module.cc:5154)
==8747== by 0x767BC0: load_needed(pointer_info*) (module.cc:5154)
==8747== by 0x767BC0: load_needed(pointer_info*) (module.cc:5154)
==8747== by 0x767BB5: load_needed(pointer_info*) (module.cc:5153)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/108925] memory leak of gfc_get_namespace result
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
@ 2023-03-06 19:23 ` mikael at gcc dot gnu.org
2023-03-06 19:40 ` anlauf at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: mikael at gcc dot gnu.org @ 2023-03-06 19:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> ---
Can't reproduce with simple examples, testcase?
I have used the following case, it does show some leaks, but none with
load_needed in the backtrace.
module m
integer i
end module m
module n
use m
contains
subroutine s(a)
integer a
i = a
end subroutine
end module n
program p
use n
call s(0)
print *, i
end program
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/108925] memory leak of gfc_get_namespace result
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
2023-03-06 19:23 ` [Bug fortran/108925] " mikael at gcc dot gnu.org
@ 2023-03-06 19:40 ` anlauf at gcc dot gnu.org
2023-03-06 19:47 ` mikael at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-03-06 19:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
The attachment in pr68800 may serve as a starting point:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=36964
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/108925] memory leak of gfc_get_namespace result
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
2023-03-06 19:23 ` [Bug fortran/108925] " mikael at gcc dot gnu.org
2023-03-06 19:40 ` anlauf at gcc dot gnu.org
@ 2023-03-06 19:47 ` mikael at gcc dot gnu.org
2023-03-06 19:52 ` anlauf at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: mikael at gcc dot gnu.org @ 2023-03-06 19:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #2)
> The attachment in pr68800 may serve as a starting point:
>
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36964
Thanks, reduced:
MODULE m
TYPE :: a
END TYPE
END MODULE
USE m
END
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/108925] memory leak of gfc_get_namespace result
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
` (2 preceding siblings ...)
2023-03-06 19:47 ` mikael at gcc dot gnu.org
@ 2023-03-06 19:52 ` anlauf at gcc dot gnu.org
2023-03-06 20:00 ` mikael at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-03-06 19:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #4 from anlauf at gcc dot gnu.org ---
Also:
MODULE m
contains
subroutine bar (arg, res)
class(*) :: arg
character(100) :: res
end subroutine
END MODULE
USE m
END
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/108925] memory leak of gfc_get_namespace result
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
` (3 preceding siblings ...)
2023-03-06 19:52 ` anlauf at gcc dot gnu.org
@ 2023-03-06 20:00 ` mikael at gcc dot gnu.org
2023-03-07 11:41 ` mikael at gcc dot gnu.org
2023-03-08 19:52 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: mikael at gcc dot gnu.org @ 2023-03-06 20:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
This does NOT improve things:
diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
index 601497e0998..2d6c7b8ef73 100644
--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -5258,7 +5258,10 @@ read_cleanup (pointer_info *p)
vtypes - their name is fine for a symtree and reduces the
namespace pollution. */
st = gfc_find_symtree (ns->sym_root, p->u.rsym.sym->name);
- if (!st)
+ if (st)
+ /* The symtree is reassigned below. */
+ st->n.sym->refs--;
+ else
st = gfc_new_symtree (&ns->sym_root, p->u.rsym.sym->name);
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/108925] memory leak of gfc_get_namespace result
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
` (4 preceding siblings ...)
2023-03-06 20:00 ` mikael at gcc dot gnu.org
@ 2023-03-07 11:41 ` mikael at gcc dot gnu.org
2023-03-08 19:52 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: mikael at gcc dot gnu.org @ 2023-03-07 11:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 54598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54598&action=edit
Tentative patch
Indeed the namespaces created during module loading are not stored anywhere, so
they are leaked basically. As they are the pieces holding symbols, which
themselves hold other things, etc, all these are leaked as well.
The attached patch stores in the current namespace a tree of module namespaces,
and use those namespaces when loading a symbol from a module. For a symbol
that is present in a module, this means that its sym->ns will be the module
namespace, even if its sym->ns was not the module namespace at the time it was
written. This makes a difference for symbols that are present in more than one
namespace, but I'm not sure how important that difference is.
This seems to work on the reduced testcases, can't fully test right now.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug fortran/108925] memory leak of gfc_get_namespace result
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
` (5 preceding siblings ...)
2023-03-07 11:41 ` mikael at gcc dot gnu.org
@ 2023-03-08 19:52 ` anlauf at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-03-08 19:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #6)
> Created attachment 54598 [details]
> Tentative patch
> This seems to work on the reduced testcases, can't fully test right now.
I tried it and killed regtesting really rather early ...
So it might be better to wait for stage1 before pursuing this further.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-03-08 19:52 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-24 12:32 [Bug fortran/108925] New: memory leak of gfc_get_namespace result rguenth at gcc dot gnu.org
2023-03-06 19:23 ` [Bug fortran/108925] " mikael at gcc dot gnu.org
2023-03-06 19:40 ` anlauf at gcc dot gnu.org
2023-03-06 19:47 ` mikael at gcc dot gnu.org
2023-03-06 19:52 ` anlauf at gcc dot gnu.org
2023-03-06 20:00 ` mikael at gcc dot gnu.org
2023-03-07 11:41 ` mikael at gcc dot gnu.org
2023-03-08 19:52 ` anlauf 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).