http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #9 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-02-05 21:04:18 UTC --- So the complete valgrind error message I get (with the comment #4 testcase fixed per Tobias instructions in comment #6) is: ==14281== Invalid read of size 4 ==14281== at 0x528B66: resolve_symbol (resolve.c:10559) ==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386) ==14281== by 0x532503: resolve_types (resolve.c:13859) ==14281== by 0x527473: gfc_resolve (resolve.c:13959) ==14281== by 0x528C18: resolve_symbol (resolve.c:12715) ==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386) ==14281== by 0x532503: resolve_types (resolve.c:13859) ==14281== by 0x527473: gfc_resolve (resolve.c:13959) ==14281== by 0x51ABBC: gfc_parse_file (parse.c:4594) ==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250) ==14281== by 0x909CDC: do_compile (toplev.c:557) ==14281== by 0x90A853: toplev_main (toplev.c:2014) ==14281== Address 0x5ca8700 is 32 bytes inside a block of size 304 free'd ==14281== at 0x4C270BD: free (vg_replace_malloc.c:366) ==14281== by 0x546E91: gfc_undo_symbols (symbol.c:2898) ==14281== by 0x514F5A: reject_statement (parse.c:1743) ==14281== by 0x515A54: decode_statement (parse.c:316) ==14281== by 0x516D8C: next_statement (parse.c:778) ==14281== by 0x51801D: parse_spec (parse.c:2379) ==14281== by 0x51A9BD: gfc_parse_file (parse.c:4297) ==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250) ==14281== by 0x909CDC: do_compile (toplev.c:557) ==14281== by 0x90A853: toplev_main (toplev.c:2014) ==14281== by 0x5712C4C: (below main) (libc-start.c:226) ==14281== ==14281== Invalid read of size 8 ==14281== at 0x52869D: resolve_symbol (resolve.c:12726) ==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386) ==14281== by 0x532503: resolve_types (resolve.c:13859) ==14281== by 0x527473: gfc_resolve (resolve.c:13959) ==14281== by 0x528C18: resolve_symbol (resolve.c:12715) ==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386) ==14281== by 0x532503: resolve_types (resolve.c:13859) ==14281== by 0x527473: gfc_resolve (resolve.c:13959) ==14281== by 0x51ABBC: gfc_parse_file (parse.c:4594) ==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250) ==14281== by 0x909CDC: do_compile (toplev.c:557) ==14281== by 0x90A853: toplev_main (toplev.c:2014) ==14281== Address 0x5ca87e0 is 256 bytes inside a block of size 304 free'd ==14281== at 0x4C270BD: free (vg_replace_malloc.c:366) ==14281== by 0x546E91: gfc_undo_symbols (symbol.c:2898) ==14281== by 0x514F5A: reject_statement (parse.c:1743) ==14281== by 0x515A54: decode_statement (parse.c:316) ==14281== by 0x516D8C: next_statement (parse.c:778) ==14281== by 0x51801D: parse_spec (parse.c:2379) ==14281== by 0x51A9BD: gfc_parse_file (parse.c:4297) ==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250) ==14281== by 0x909CDC: do_compile (toplev.c:557) ==14281== by 0x90A853: toplev_main (toplev.c:2014) ==14281== by 0x5712C4C: (below main) (libc-start.c:226) So the problem seems to be that when we hit the error in the interface declaration, we call gfc_undo_symbols() -> gfc_release_symbol() -> gfc_free_symbol() -> free(), but then we go and dereference pointers to this freed memory. Unfortunately I'm not really familiar enough with this part of the codebase to know how to fix it properly.
