Help Please - PR18923 segfault after subroutine name confusion

[Jerry DeLisle <jvdelisle at verizon dot net>]

In my investigation of these problems on invalid code I have been able to get 
rid of the segfaults in the subject PR.  Now I am at a point where we encounter 
an internal_error in gfc_get_default_type which is caused by a garbage symbol 
name. (yes I know, garbage in garbage out)

I have been able to trace this to resolve_variable where gfc_set_default_type is 
called if the variable type is unknown.

Doing the following avoids the internal error but does not really solve the 
problem. (This little patchlet even passes regression testing but seems to me to 
be nonsense)

Index: resolve.c
===================================================================
--- resolve.c   (revision 125119)
+++ resolve.c   (working copy)
@@ -3134,6 +3134,7 @@ resolve_variable (gfc_expr *e)
   else
     {
       /* Must be a simple variable reference.  */
+      sym->name = e->symtree->name;
       if (gfc_set_default_type (sym, 1, sym->ns) == FAILURE)
        return FAILURE;
       e->ts = sym->ts;


Now to the point.  This allows the compiler to seemingly proceed to an orderly 
conclusion.  However, using valgrind I have discovered that:

==533== ERROR SUMMARY: 156 errors from 77 contexts (suppressed: 5 from 1)
==533== malloc/free: in use at exit: 306,331 bytes in 891 blocks.
==533== malloc/free: 1,496 allocs, 605 frees, 506,729 bytes allocated.
==533== For counts of detected errors, rerun with: -v
==533== searching for pointers to 891 not-freed blocks.
==533== checked 3,091,352 bytes.

Almost all of these are:

==533== Invalid read of size 8
==533==    at 0x41DED9: check_restricted (expr.c:2203)
==533==    by 0x41DFE4: restricted_args (expr.c:2074)
==533==    by 0x44DF54: resolve_index_expr (resolve.c:5497)
==533==    by 0x44DFA8: resolve_charlen (resolve.c:5517)
==533==    by 0x44F748: resolve_types (resolve.c:7403)
==533==    by 0x44F82A: resolve_types (resolve.c:7416)
==533==    by 0x451C6C: gfc_resolve (resolve.c:7479)
==533==    by 0x446257: gfc_parse_file (parse.c:3248)
==533==    by 0x465D9D: gfc_be_parse_file (f95-lang.c:303)
==533==    by 0x681B53: toplev_main (toplev.c:1051)
==533==    by 0x35E2A1DA43: (below main) (in /lib64/libc-2.5.so)
==533==  Address 0x4CAF710 is 0 bytes inside a block of size 224 free'd
==533==    at 0x4A0548E: free (vg_replace_malloc.c:233)
==533==    by 0x45C893: gfc_undo_symbols (symbol.c:2364)
==533==    by 0x442873: reject_statement (parse.c:1324)
==533==    by 0x445D70: parse_contained (parse.c:2869)
==533==    by 0x4460CB: parse_progunit (parse.c:2965)
==533==    by 0x44635D: gfc_parse_file (parse.c:3202)
==533==    by 0x465D9D: gfc_be_parse_file (f95-lang.c:303)
==533==    by 0x681B53: toplev_main (toplev.c:1051)
==533==    by 0x35E2A1DA43: (below main) (in /lib64/libc-2.5.so)


Worthy of note is that there is a problem occurring in gfc_undo_symbols when we 
reject a statement.  We do a lot of reject statements with invalid code.

I suspect somewhere along the line, items have been added to gfc_symbol that are 
not getting freed, leaving pointers to garbage.  Looking at gfc_free_symbol, I 
wonder if we need to free more things. I could go through all the structures to 
see if we are missing something.

I was hoping this email might prompt some memory of someone who may have added 
stuff to gfc_symbol or one of the other structures and not taken care of it in 
gfc_undo_symbol to save me some hunting time.  It could also be down in one of 
the following:

  gfc_free_array_spec (sym->as);

  free_components (sym->components);

  gfc_free_expr (sym->value);

  gfc_free_namelist (sym->namelist);

  gfc_free_namespace (sym->formal_ns);

  if (!sym->attr.generic_copy)
    gfc_free_interface (sym->generic);

  gfc_free_formal_arglist (sym->formal);

  gfc_free (sym);
}

Thanks in advance,

Jerry