[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[mikael at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Mikael Morin  ---
(In reply to Jürgen Reuter from comment #5)
> I checked again, and I don't see any issues any more. There might still be
> some memory leaks, I haven't checked. Would it make sense to close this one
> and open a new report in case there is a definite reproducer?

Yes, assuming fixed. Closing.

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[juergen.reuter at desy dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

--- Comment #5 from Jürgen Reuter  ---
I checked again, and I don't see any issues any more. There might still be some
memory leaks, I haven't checked. Would it make sense to close this one and open
a new report in case there is a definite reproducer?

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #4 from janus at gcc dot gnu.org ---

 These invalid write/read disappear
 with r195140 (2013-01-14).

I can confirm that I don't see any of these guys with current trunk.


 However I see a lot leak

Yes, valgrind definitely reports a good number of leaks, also with current
trunk. Unfortunately the test case is still quite a monstrosity ...

Note that we have a couple of memleak PRs already, e.g.:
 * PR 38319
 * PR 41936
 * PR 55603
 * PR 58557

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 The example works with gfortran 4.8.x and 4.9.0, but fails with all 4.7.x. 

I have built and ran the test without problem with 4.8.2 and almost latest
trunk without problem (few runs) and got random problems with 4.7.4. I'll try
to do some bisection to see it is known issue that has been fixed between 4.7
and 4.8, but don't expect a quick answer.

I would be nice if you can reduce your test further.

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[juergen.reuter at desy dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

--- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 31895
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31895action=edit
bit smaller test case

This is a bit smaller test case. The main program is basically a call, and one
module has been eliminated. Also, no input file is needed any more. 
The module ifile defines internal files used for 
carrying information, lexer.f90 defines the lexer, parser.f90 the parser,
syntax_rules.f90 the corresponding syntax_rules. 
The scan command now only has one line which triggers the problems.

[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881

--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
When the executable is run under valgrind I see a lot of

==981== Invalid write of size 8
==981==at 0x100020B99: __parser_MOD_token_assign_real (in ./seg_prod)
==981==by 0x10001ED21: __parser_MOD_parse_node_set_value (in ./seg_prod)
==981==by 0x100058249: __commands_MOD_range_real_set_value (in ./seg_prod)
==981==by 0x1000543C2: __commands_MOD_cmd_scan_execute (in ./seg_prod)
==981==by 0x100053EC9: __commands_MOD_command_list_execute (in ./seg_prod)
==981==by 0x10005E495: __whizard_MOD_whizard_process_stream (in ./seg_prod)
==981==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod)
==981==by 0x10006191E: MAIN__ (in ./seg_prod)
==981==by 0x10006204E: main (in ./seg_prod)
==981==  Address 0x100f0400d is 829 bytes inside a block of size 1,024 free'd
==981==at 0x10009252D: free (vg_replace_malloc.c:430)
==981==by 0x1A624: __iso_varying_string_MOD_op_eq_vs_vs (in ./seg_prod)
==981==by 0x10002830D: __variables_MOD_var_list_get_var_ptr (in ./seg_prod)
==981==by 0x10002839D: __variables_MOD_var_list_get_var_ptr (in ./seg_prod)
==981==by 0x100024DE2: __variables_MOD_var_list_check_user_var (in
./seg_prod)
==981==by 0x10005C9E0: __commands_MOD_cmd_var_compile (in ./seg_prod)
==981==by 0x100053F86: __commands_MOD_command_list_compile (in ./seg_prod)
==981==by 0x10005B43E: __commands_MOD_build_alt_setup (in ./seg_prod)
==981==by 0x10005450A: __commands_MOD_cmd_scan_execute (in ./seg_prod)
==981==by 0x100053EC9: __commands_MOD_command_list_execute (in ./seg_prod)
==981==by 0x10005E495: __whizard_MOD_whizard_process_stream (in ./seg_prod)
==981==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod)

when compiled with r194897 (2013-01-04). These invalid write/read disappear
with r195140 (2013-01-14). However I see a lot leak

...
=65053== 40,519 (7,344 direct, 33,175 indirect) bytes in 51 blocks are
definitely lost in loss record 126 of 128
==65053==at 0x100092679: malloc (vg_replace_malloc.c:266)
==65053==by 0x10001E6F0: __parser_MOD_parse_node_replace_last_sub (in
./seg_prod)
==65053==by 0x100057270: __commands_MOD_cmd_scan_compile (in ./seg_prod)
==65053==by 0x100053F5E: __commands_MOD_command_list_compile (in
./seg_prod)
==65053==by 0x10005E465: __whizard_MOD_whizard_process_stream (in
./seg_prod)
==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in
./seg_prod)
==65053==by 0x10006191E: MAIN__ (in ./seg_prod)
==65053==by 0x10006204E: main (in ./seg_prod)
==65053==
==65053== 54,812 (8,432 direct, 46,380 indirect) bytes in 28 blocks are
definitely lost in loss record 127 of 128
==65053==at 0x100092679: malloc (vg_replace_malloc.c:266)
==65053==by 0x100056A16: __commands_MOD_cmd_scan_compile (in ./seg_prod)
==65053==by 0x100053F5E: __commands_MOD_command_list_compile (in
./seg_prod)
==65053==by 0x10005E465: __whizard_MOD_whizard_process_stream (in
./seg_prod)
==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in
./seg_prod)
==65053==by 0x10006191E: MAIN__ (in ./seg_prod)
==65053==by 0x10006204E: main (in ./seg_prod)
==65053==
==65053== 218,271 (144 direct, 218,127 indirect) bytes in 1 blocks are
definitely lost in loss record 128 of 128
==65053==at 0x100092679: malloc (vg_replace_malloc.c:266)
==65053==by 0x10001EBC3: __parser_MOD_parse_node_create_branch (in
./seg_prod)
==65053==by 0x10001D271: parse_sequence.2386 (in ./seg_prod)
==65053==by 0x10001DD29: parse_node_match_rule.2402 (in ./seg_prod)
==65053==by 0x10001CD3B: __parser_MOD_parse_tree_init (in ./seg_prod)
==65053==by 0x10005E3FD: __whizard_MOD_whizard_process_stream (in
./seg_prod)
==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in
./seg_prod)
==65053==by 0x10006191E: MAIN__ (in ./seg_prod)
==65053==by 0x10006204E: main (in ./seg_prod)
==65053==
==65053== LEAK SUMMARY:
==65053==definitely lost: 79,291 bytes in 763 blocks
==65053==indirectly lost: 330,636 bytes in 3,687 blocks
==65053==  possibly lost: 0 bytes in 0 blocks
==65053==still reachable: 556 bytes in 12 blocks
==65053== suppressed: 88 bytes in 1 blocks
==65053==
==65053== For counts of detected and suppressed errors, rerun with: -v
==65053== ERROR SUMMARY: 19 errors from 19 contexts (suppressed: 0 from 0)

Note that on trunk I also get a lot of invalid write/read (114).