From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id DADDF3858D3C; Tue,  7 Mar 2023 11:41:12 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DADDF3858D3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678189272;
	bh=FmPUMiMbhPjUw4rATVxtL3DB4S40COvLT4EjJGQtLl0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=LJyEWGI/QBrod/olOBNCIVgjaNDtPMiHAlW3pAZoK8KTg8AWbGXJ2gAX9x4Kx8IXb
	 TmKeYlXfugaEZAWTb3vu2rXF07LQS2eBOZol80VL6dEH9TjFipHqdgFKtZTECSWepp
	 7d8QKtoltwOAqBAz9w8El2Jt3/NxBFuXWhYAtO3Q=
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/108925] memory leak of gfc_get_namespace result
Date: Tue, 07 Mar 2023 11:41:12 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-108925-4-QjH0uySKXV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108925-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108925-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108925

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 54598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54598&action=3Dedit
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 namespa=
ces,
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.=