[Bug fortran/108925] New: memory leak of gfc_get_namespace result

[Bug fortran/108925] New: memory leak of gfc_get_namespace result

[rguenth at gcc dot gnu.org]

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)

[Bug fortran/108925] memory leak of gfc_get_namespace result

[mikael at gcc dot gnu.org]

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

[Bug fortran/108925] memory leak of gfc_get_namespace result

[anlauf at gcc dot gnu.org]

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

[Bug fortran/108925] memory leak of gfc_get_namespace result

[mikael at gcc dot gnu.org]

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

[Bug fortran/108925] memory leak of gfc_get_namespace result

[anlauf at gcc dot gnu.org]

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

[Bug fortran/108925] memory leak of gfc_get_namespace result

[mikael at gcc dot gnu.org]

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);
        }

[Bug fortran/108925] memory leak of gfc_get_namespace result

[mikael at gcc dot gnu.org]

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.

[Bug fortran/108925] memory leak of gfc_get_namespace result

[anlauf at gcc dot gnu.org]

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.