Hi Tobias,
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index c612b492f3e..326e6f5db7a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -9819,6 +9819,15 @@ gfc_match_submod_proc (void)
if (gfc_match_eos () != MATCH_YES)
{
+ /* Unset st->n.sym. Note: in reject_statement (), the symbol
changes are
+ undone, such that the st->n.sym->formal points to the
original symbol;
+ if now this namespace is finalized, the formal namespace is
freed,
+ but it might be still needed in the parent namespace. */
+ gfc_symtree *st = gfc_find_symtree (gfc_current_ns->sym_root,
sym->name);
+ st->n.sym = NULL;
Don't we need free or unlink the st node from the symtree, too?
+ gfc_free_symbol (sym->tlink);
+ sym->tlink = NULL;
+ sym->refs--;
gfc_syntax_error (ST_MODULE_PROC);
return MATCH_ERROR;
}
Regards,
Andre
On Sat, 12 Sep 2020 23:00:12 +0200
Tobias Burnus <bur...@net-b.de> wrote:
> The testcase for PR93423 did a double free, which caused
> an ICE. That's reported in PR96041.
>
> Slightly frustrated by the FAIL in the testsuite,
> I decided to debug and, hopefully, fix this.
>
> The problem is related to putting the symtree
> into a sub namespace of the symbol's ns. That's fixed up
> by copying things around – except in the error case where
> all those fixups are undone. Thus, when the symbol tree
> is deleted, the parent's sym->formal->sym is also deleted,
> causing an ICE in resolve_formal_arguments.
>
> Hopefully, I got this all right...
> I see still one memory leak for a symbol in module.c
> according to valgrind, but I don't know whether it is
> related to those symbols. (There are a lot of other leaks,
> mostly related to polymorphism (vtab etc.).)
>
> OK for the trunk?
>
> Tobias
>
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 178 3837536 * ve...@gmx.de
