Hi Tobias,

This is OK.

Thanks for the patch and the extra careful regtesting :-)

Paul

On Fri, 12 Oct 2018 at 00:17, Tobias Burnus <bur...@net-b.de> wrote:
>
> Next patch, next try …
>
> The problem is the following: We have a use-associated symbol (a
> function) – which is once referenced (by use association).
>
> We now declare a same-name function in the 'contains' section.
>
> gfortran now parses the function name, fetches the symbol and reports
> that one duplicates the function (gfc_error_now). However, it continues
> afterwards and creates a sym_tree in the gfc_current_ns – and duly
> increases the sym->refs to 2.
>
> A bit later, the function gets rejected. (Parsing of the formal
> arguments fails when setting a attribute of a use-associated symbol, but
> I think this doesn't matter. reject_statement() is called, which rolls
> back the symbol, but again, I think that doesn't matter – it just makes
> some other solutions a tad more difficult.)
>
> Now, the contains namespace is cleaned up: As the function name is in
> the namespace's sym_tree, gfc_release_symbol() is invoked.
>
> The symbol itself is not freed (as --refs > 0), but sym->formal_ns is.
> (There are some safety nets, like sym->rev == 2 and sym->ns !=
> sym->formal_ns, but they don't help.)
>
> Later, the symbol of the parent's namespace is resolved – and this
> includes resolving the formal arguments. – And accessing freed memory
> might crash gfortran.
>
> As solution, I return early and with an error from get_proc_name(). I
> think that's cleaner than waiting longer – and the early return avoids
> creating the symbol at the first place. (Otherwise, modifications have
> to go beyond rolling back of the symbols; doing refs++ probably helps,
> but is rather intransparent.)
>
>
> Pro of the early return: Avoids accessing already freed memory, might
> generate shorter error output as some later fails (like for not being
> able to modify attributes of a use-associated symbol) are gone.
>
> Contra: As one returns before entering a procedure, all following lines
> are in the outer scope (usually 'contains') and there probably
> unexpected. Hence, one might get a bunch of follow-up errors which do
> not help.
>
>
> Build on x86-64 and even more carefully regtested.
>
> OK?
>
> Tobias
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Reply via email to