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

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

[juergen.reuter at desy dot de]

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

            Bug ID: 59881
           Summary: Memory corruption with allocatable arrays in
                    polymorphic types
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juergen.reuter at desy dot de

Created attachment 31891
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31891&action=edit
Tar ball that produces code triggering the memory corruption.

The code attached (unpack, do make, make run) triggers the memory leak. Sorry
for not being able/having time to reduce the case further. The propgram
./seg_prod reads in the file structure_5.sin specifying a scan over integer and
real values that is steered in commands.f90 via the type range_t. First there
is some test output (the internal tree-like syntax structure we use),the
trivial examples pass, the final example with a multi-component range fails.
The example works with gfortran 4.8.x and 4.9.0, but fails with all 4.7.x. 
Sometimes the values are forgotten, sometimes a memory leak appears. We were
able to program around this, but nevertheless wanted to file a bug report. 
Here in our svn commit you can see how we basically removed one layer of
polymorphism for the type range_t:
https://whizard.hepforge.org/trac/changeset/5096
Furthermore, the finalizer range_final then worked again. Hope, you can boil
this down to the essential part.

[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=31895&action=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.
>From gcc-bugs-return-440940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jan 19 21:24:53 2014
Return-Path: <gcc-bugs-return-440940-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4875 invoked by alias); 19 Jan 2014 21:24:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4837 invoked by uid 48); 19 Jan 2014 21:24:50 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
Date: Sun, 19 Jan 2014 21:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59880-4-3Ofj99AliZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59880-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59880-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg02082.txt.bz2
Content-length: 336

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY880

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> Sure, will do.  Thought about that as well, just didn't change it before
> attaching ;)

Please use "long long" and target ! ia32 on testcase so
that it will be tested for x32.

[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 0x10000A624: __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).

[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

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter <juergen.reuter at desy dot de> ---
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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
(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.