[Bug fortran/94788] New: Severe regression leading to double free in tcache

[Bug fortran/94788] New: Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

            Bug ID: 94788
           Summary: Severe regression leading to double free in tcache
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Unfortunately, just a week or so before the release there was a very severe
regression, which leads to a double free corruption in tcache, cf. below.
Unfortunately, it is tough to come up with a short reproducer because the case
where we see this problem is where our program (written in Fortran) generates
code, compiles it, links it, and runs it. Our code is rather large, and needs
OCaml to generate a reproducer. The code can be found here:
https://whizard.tp.nt.uni-siegen.de/
(nightly snapshot). As I said, to build it, you'd need OCaml, then do 
configure, make, make check. 
make check runs first in the subpackages circe2, omega, vamp, and then
in tests/unit_tests
There, the test simulations fails in its 10th sub-test with the corruption
below. 


free(): double free detected in tcache 2

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7f27812c6ba0 in ???
#1  0x7f27812c5df5 in ???
#2  0x7f2780f2583f in ???
#3  0x7f2780f257bb in ???
#4  0x7f2780f10534 in ???
#5  0x7f2780f67507 in ???
#6  0x7f2780f6dc19 in ???
#7  0x7f2780f6f6fc in ???
#8  0x545539 in __simulations_uti_MOD_simulations_10
        at
/builds/whizard/development/build/src/whizard-core/simulations_uti.f90:1239
#9  0x7f278209cec9 in __unit_tests_MOD_test
        at /builds/whizard/development/build/src/testing/unit_tests.f90:175
#10  0x522c12 in __simulations_ut_MOD_simulations_test
        at
/builds/whizard/development/build/src/whizard-core/simulations_ut.f90:72
#11  0x43e2cd in whizard_check
        at /builds/whizard/development/build/src/whizard-core/main_ut.f90:715
#12  0x43e2cd in main_ut
        at /builds/whizard/development/build/src/whizard-core/main_ut.f90:303
#13  0x4335ae in main
        at /builds/whizard/development/build/src/whizard-core/main_ut.f90:31
Aborted (core dumped)
FAIL simulations.run (exit status: 134)

[Bug fortran/94788] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter <juergen.reuter at desy dot de> ---
The change must have happened between Sunday, April 16 and Monday, April 27.

[Bug fortran/94788] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter <juergen.reuter at desy dot de> ---
This is our unit test, we now confirmed that this is the only problem, so the
only failing test: it really looks like that the finalizer for the subroutine
crashes, all routines inside the subroutine get executed correctly:
  subroutine simulations_10 (u)
    integer, intent(in) :: u
    type(string_t) :: libname, procname1, expr_text
    type(rt_data_t), target :: global
    type(rt_data_t), dimension(1), target :: alt_env
    type(ifile_t) :: ifile
    type(stream_t) :: stream
    type(parse_tree_t) :: pt_weight
    type(simulation_t), target :: simulation
    type(event_sample_data_t) :: data

    write (u, "(A)")  "* Test output: simulations_10"
    write (u, "(A)")  "*   Purpose: reweight event"
    write (u, "(A)")

    write (u, "(A)")  "* Initialize processes"
    write (u, "(A)")

    call syntax_model_file_init ()
    call syntax_pexpr_init ()

    call global%global_init ()
    call global%set_log (var_str ("?omega_openmp"), &
         .false., is_known = .true.)
    call global%set_int (var_str ("seed"), &
         0, is_known = .true.)

    libname = "simulation_10a"
    procname1 = "simulation_10p"

    call prepare_test_library (global, libname, 1, [procname1])
    call compile_library (libname, global)

    call global%append_log (&
         var_str ("?rebuild_phase_space"), .true., intrinsic = .true.)
    call global%append_log (&
         var_str ("?rebuild_grids"), .true., intrinsic = .true.)
    call global%append_log (&
         var_str ("?rebuild_events"), .true., intrinsic = .true.)

    call global%set_string (var_str ("$method"), &
         var_str ("unit_test"), is_known = .true.)
    call global%set_string (var_str ("$phs_method"), &
         var_str ("single"), is_known = .true.)
    call global%set_string (var_str ("$integration_method"),&
         var_str ("midpoint"), is_known = .true.)
    call global%set_log (var_str ("?vis_history"),&
         .false., is_known = .true.)
    call global%set_log (var_str ("?integration_timer"),&
         .false., is_known = .true.)
    call global%set_log (var_str ("?recover_beams"), &
         .false., is_known = .true.)

    call global%set_real (var_str ("sqrts"),&
         1000._default, is_known = .true.)

    call global%it_list%init ([1], [1000])

    call global%set_string (var_str ("$run_id"), &
         var_str ("simulations1"), is_known = .true.)
    call integrate_process (procname1, global, local_stack=.true.)

    write (u, "(A)")  "* Initialize alternative environment with custom weight"
    write (u, "(A)")

    call alt_env(1)%local_init (global)
    call alt_env(1)%activate ()

    expr_text = "2"
    write (u, "(A,A)")  "weight = ", char (expr_text)
    write (u, *)

    call ifile_clear (ifile)
    call ifile_append (ifile, expr_text)
    call stream_init (stream, ifile)
    call parse_tree_init_expr (pt_weight, stream, .true.)
    call stream_final (stream)
    alt_env(1)%pn%weight_expr => pt_weight%get_root_ptr ()
    call alt_env(1)%write_expr (u)

    write (u, "(A)")
    write (u, "(A)")  "* Initialize event generation"
    write (u, "(A)")

    call global%set_log (var_str ("?unweighted"), &
         .false., is_known = .true.)
    call simulation%init ([procname1], .true., .true., global, alt_env=alt_env)
    call simulation%init_process_selector ()

    data = simulation%get_data ()
    call data%write (u)

    write (u, "(A)")
    write (u, "(A)")  "* Generate an event"
    write (u, "(A)")

    call simulation%generate (1)
    call simulation%write (u)

    write (u, "(A)")
    write (u, "(A)")  "* Write the event record for the last event"
    write (u, "(A)")

    call simulation%write_event (u)

    write (u, "(A)")
    write (u, "(A)")  "* Write the event record for the alternative setup"
    write (u, "(A)")

    call simulation%write_alt_event (u)

    print *, "written alt_event, starting cleanup ..."

    write (u, "(A)")
    write (u, "(A)")  "* Cleanup"

    call simulation%final ()
    print *, "simulation finalized"
    call global%final ()
    print *, "global finalized"

    call syntax_model_file_final ()
    print *, "syntax_model_file finalized"
    call syntax_pexpr_final ()
    print *, "syntax pexpr finalized"

    write (u, "(A)")
    write (u, "(A)")  "* Test output end: simulations_10"

  end subroutine simulations_10

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Summary|Severe regression leading   |[10 Regression] Severe
                   |to double free in tcache    |regression leading to
                   |                            |double free in tcache
           Priority|P3                          |P4
   Target Milestone|---                         |10.0

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you maybe bisect this to a specific (fortran) commit in GCC?

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #4 from Jürgen Reuter <juergen.reuter at desy dot de> ---
It is definitely this routine in our code that triggers this double free error:
call simulation%init ([procname1], .true., .true., global, alt_env=alt_env)
It really looks like that the garbage collector is mistreating the Fortran
routines, and chokes in finalizing the subroutine.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?

This does not necessarily be a Fortran specific commit, it could also be a
change in the middle-end or backend which created some unforeseen "feature" in
the fortran end.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[simon.brass at desy dot de]

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

--- Comment #6 from Simon Braß <simon.brass at desy dot de> ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?

FYI, I'm hooking up with the bisect (I'm a colleague of Jürgen).
I will post an update as fast as possible, reasonably, tomorrow.

Cheers,
Simon.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[simon.brass at desy dot de]

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

--- Comment #7 from Simon Braß <simon.brass at desy dot de> ---
(In reply to Simon Braß from comment #6)
> (In reply to Richard Biener from comment #3)
> > Can you maybe bisect this to a specific (fortran) commit in GCC?
> 
> FYI, I'm hooking up with the bisect (I'm a colleague of Jürgen).
> I will post an update as fast as possible, reasonably, tomorrow.
> 
> Cheers,
> Simon.

After bisecting the commits of the last 8 days, the offending commit is:

Author: Thomas König <tkoenig@gcc.gnu.org>  2020-04-23 20:30:01
Committer: Thomas König <tkoenig@gcc.gnu.org>  2020-04-23 20:30:01
Parent: dcf69ac5448fd6a16137cfe9fe6deadd0ec0243d (coroutines, libstdc++-v3:
Update to n4861 C++20 DIS.)
Child:  bca558de2a24b2a78c6a321d6cec384e07759d77 (tree: Fix up get_narrower
[PR94724])
Branches: master, remotes/origin/devel/c++-coroutines, remotes/origin/master
Follows: misc/cutover-git
Precedes: 

    Fix PR 93956, wrong pointer when returned via function.

    This one took a bit of detective work.  When array pointers point
    to components of derived types, we currently set the span field
    and then create an array temporary when we pass the array
    pointer to a procedure as a non-pointer or non-target argument.
    (This is inefficient, but that's for another release).

    Now, the compiler detected this case when there was a direct assignment
    like p => a%b, but not when p was returned either as a function result
    or via an argument.  This patch fixes that.

    2020-04-23  Thomas Koenig  <tkoenig@gcc.gnu.org>

        PR fortran/93956
        * expr.c (gfc_check_pointer_assign): Also set subref_array_pointer
        when a function returns a pointer.
        * interface.c (gfc_set_subref_array_pointer_arg): New function.
        (gfc_procedure_use): Call it.

    2020-04-23  Thomas Koenig  <tkoenig@gcc.gnu.org>

        PR fortran/93956
        * gfortran.dg/pointer_assign_13.f90: New test.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
I'd like to understand what went wrong here... I suspect that
the fix exposed another bug somewhere :-(

Is it possible to isolate a test case like that?  If that is
the offending patch, I think it is probably about a pointer to a
variable of a derived type, either via a function or as
an argument (look at the test case to see what the patch
fixes).

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Thomas Koenig from comment #8)
> I'd like to understand what went wrong here... I suspect that
> the fix exposed another bug somewhere :-(
> 
> Is it possible to isolate a test case like that?  If that is
> the offending patch, I think it is probably about a pointer to a
> variable of a derived type, either via a function or as
> an argument (look at the test case to see what the patch
> fixes).

I'm on the way to condense the reproducer. At latest tomorrow you will get it.
I really hope we get this fixed before the gcc 10 release.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?

Richard, when is the last time (presumably) that either a fix can go in or
the patch can be reverted?

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Thomas Koenig from comment #10)
> (In reply to Richard Biener from comment #3)
> > Can you maybe bisect this to a specific (fortran) commit in GCC?
> 
> Richard, when is the last time (presumably) that either a fix can go in or
> the patch can be reverted?

For the moment, I would really advice to revert this patch. It is definitely
not kosher and it is way too close to the gcc 10 release. If gcc 10 gets
released this way, we have to special-case the whole release. This would mean a
severe workload for us.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #12 from Jürgen Reuter <juergen.reuter at desy dot de> ---
fuck, sdill too big :(

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #13 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I will submit a reproducer, unpack it, do 'make', then execute
./whizard_test --check simulations.
Still trying to get this below 1 MB. :(
In case you cannot fix this, please, Thomas, please, revert this. This cannot
be released like that.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #14 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 48387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48387&action=edit
Reproducer, first try

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #15 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Wow, I have a first version, finally.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #16 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 48388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48388&action=edit
2nd reproducer, down to 800 kb

Now you can do just ./whizard_check to run the test.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-04-27
     Ever confirmed|0                           |1

--- Comment #17 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Thanks for the reproducer, this is definitely fishy.

valgrind shows:

==21250== Invalid free() / delete / delete[] / realloc()
==21250==    at 0x4C2F3B9: free (vg_replace_malloc.c:540)
==21250==    by 0x804071: __simulations_uti_MOD_simulations_10
(simulations_uti.f90:42)
==21250==    by 0x40A504: __unit_tests_MOD_test (unit_tests.f90:175)
==21250==    by 0x804EC5: __simulations_ut_MOD_simulations_test
(simulations_ut.f90:45)
==21250==    by 0x806AC5: whizard_check.0 (in
/home/ig25/Downloads/Whiz/whizard_test)
==21250==    by 0x80771A: MAIN__ (in /home/ig25/Downloads/Whiz/whizard_test)
==21250==    by 0x808733: main (in /home/ig25/Downloads/Whiz/whizard_test)
==21250==  Address 0x959ae00 is 0 bytes inside a block of size 20 free'd
==21250==    at 0x4C2F3B9: free (vg_replace_malloc.c:540)
==21250==    by 0x8009FE: __simulations_uti_MOD_simulations_10
(simulations_uti.f90:124)
==21250==    by 0x40A504: __unit_tests_MOD_test (unit_tests.f90:175)
==21250==    by 0x804EC5: __simulations_ut_MOD_simulations_test
(simulations_ut.f90:45)
==21250==    by 0x806AC5: whizard_check.0 (in
/home/ig25/Downloads/Whiz/whizard_test)
==21250==    by 0x80771A: MAIN__ (in /home/ig25/Downloads/Whiz/whizard_test)
==21250==    by 0x808733: main (in /home/ig25/Downloads/Whiz/whizard_test)
==21250==  Block was alloc'd at
==21250==    at 0x4C2E221: malloc (vg_replace_malloc.c:309)
==21250==    by 0x73EDEA: __rt_data_MOD_rt_data_activate (rt_data.f90:509)
==21250==    by 0x7FFEF2: __simulations_uti_MOD_simulations_10
(simulations_uti.f90:104)
==21250==    by 0x40A504: __unit_tests_MOD_test (unit_tests.f90:175)
==21250==    by 0x804EC5: __simulations_ut_MOD_simulations_test
(simulations_ut.f90:45)
==21250==    by 0x806AC5: whizard_check.0 (in
/home/ig25/Downloads/Whiz/whizard_test)
==21250==    by 0x80771A: MAIN__ (in /home/ig25/Downloads/Whiz/whizard_test)
==21250==    by 0x808733: main (in /home/ig25/Downloads/Whiz/whizard_test)
==21250== 

and lots more.

[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Kथà¤nig <tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:d8df7c404e233abb1e26d8b8370c460732904531

commit r10-8001-gd8df7c404e233abb1e26d8b8370c460732904531
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Mon Apr 27 23:49:36 2020 +0200

    Revert r10-7920-g06eca1acafa27e19e82dc73927394a7a4d0bdbc5 .

    2020-04-27  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/93956
            PR fortran/94788
            * expr.c (gfc_check_pointer_assign): Revert patch for PR 93956.
            * interface.c: Likewise.

    2020-04-27  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/93956
            PR fortran/94788
            * gfortran.dg/pointer_assign_13.f90: Remove.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|10.0                        |9.3.1
            Summary|[10 Regression] Severe      |[8/9 Regression] Severe
                   |regression leading to       |regression leading to
                   |double free in tcache       |double free in tcache
   Target Milestone|10.0                        |9.4

--- Comment #19 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Fixed for the upcoming release, will revert on the branches shortly.

Thanks for the bug report!

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #20 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Thanks a lot for reverting, Thomas, shall I further reduce the reproducer, or
can you work with it now?

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #21 from kargl at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #20)
> Thanks a lot for reverting, Thomas, shall I further reduce the reproducer,
> or can you work with it now?

In comment #2 you mention a finalizer.  There are 22 open
bug reports about finalization.  It is likely that Thomas's
patch uncovered yet another finalization bug.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #22 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Ok, I stop shrinking the reproducer further down for the moment, let me know if
you need more help. Thanks for your efforts.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
             Blocks|                            |93956

--- Comment #23 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #20)
> Thanks a lot for reverting, Thomas, shall I further reduce the reproducer,
> or can you work with it now?

I could use it to confirm that there is a bug, but the test case is
far too complex for analysis, and it is also not possible to put
it in the testsuite.  So, at the moment, work on PR 93956 (a F95 wrong-code
bug, hence a high priority) is effectively blocked.

So yes, I would appreciate a shorter reproducer, especially since
I plan to revisit the whole span and pointer area once gcc 10
is out of the door.

So, I'll mark this bug as WAITING for now.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
[Bug 93956] Wrong array creation with p => array_dt(1:n)%component

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschwinge at gcc dot gnu.org

--- Comment #24 from Tobias Burnus <burnus at gcc dot gnu.org> ---
*** Bug 94813 has been marked as a duplicate of this bug. ***

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #25 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Thomas Koenig from comment #23)
> (In reply to Jürgen Reuter from comment #20)
> > Thanks a lot for reverting, Thomas, shall I further reduce the reproducer,
> > or can you work with it now?
> 
> I could use it to confirm that there is a bug, but the test case is
> far too complex for analysis, and it is also not possible to put
> it in the testsuite.  So, at the moment, work on PR 93956 (a F95 wrong-code
> bug, hence a high priority) is effectively blocked.
> 
> So yes, I would appreciate a shorter reproducer, especially since
> I plan to revisit the whole span and pointer area once gcc 10
> is out of the door.
> 
> So, I'll mark this bug as WAITING for now.

Ok, Simon and I try our best, working independently, me reducing the existing
case further, and he tries to write a small reproducer from scratch.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #26 from Jürgen Reuter <juergen.reuter at desy dot de> ---
At least there is no time pressure at the moment ...

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

--- Comment #27 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #25)

> Ok, Simon and I try our best, working independently, me reducing the
> existing case further, and he tries to write a small reproducer from scratch.

Thanks a lot!

That is really appreciated.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #28 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 48392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48392&action=edit
3rd reproducer, down to 600 kb

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #29 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Is this now small enough?

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #30 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Thomas, can you work with this now!?

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #31 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 48402
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48402&action=edit
Reproducer 4, down to 210 kb

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #32 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 48404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48404&action=edit
Reproducer 5, now single file, C code gone, just needs empty Test.mdl

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #33 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
So, the first error in your reduced test case is

==8972== Invalid free() / delete / delete[] / realloc()
==8972==    at 0x4C2F3B9: free (vg_replace_malloc.c:540)
==8972==    by 0x5B2D05: __simulations_uti_MOD_simulations_10
(main_ut.f90:26224)
==8972==    by 0x5B494E: MAIN__ (main_ut.f90:26298)
==8972==    by 0x5B49BC: main (main_ut.f90:26288)
==8972==  Address 0x7ed0510 is 0 bytes inside a block of size 8 free'd
==8972==    at 0x4C2F3B9: free (vg_replace_malloc.c:540)
==8972==    by 0x5B06F9: __simulations_uti_MOD_simulations_10
(main_ut.f90:26263)
==8972==    by 0x5B494E: MAIN__ (main_ut.f90:26298)
==8972==    by 0x5B49BC: main (main_ut.f90:26288)
==8972==  Block was alloc'd at
==8972==    at 0x4C2E221: malloc (vg_replace_malloc.c:309)
==8972==    by 0x57D64E: __rt_data_MOD_rt_data_activate (main_ut.f90:24161)
==8972==    by 0x5AFED1: __simulations_uti_MOD_simulations_10
(main_ut.f90:26250)
==8972==    by 0x5B494E: MAIN__ (main_ut.f90:26298)
==8972==    by 0x5B49BC: main (main_ut.f90:26288)

where the invalid free is given in the line

    type(rt_data_t), dimension(1), target :: alt_env

and the first one in

    call simulation%init ([procname1], .true., .true., global, alt_env=alt_env)

type(rt_data_t) has a finalizer, rt_global_data_final.

Hm, not tonight, but this is something to go on (I think).

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #34 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 48411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48411&action=edit
Final reproducer, less than 300 lines ;)

This one should be sufficient. No further files or input is necessary, it seems
that the problem lies in the combination of inheriting derived types,
allocatables and pointers. All the fun.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

--- Comment #35 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #34)
> Created attachment 48411 [details]
> Final reproducer, less than 300 lines ;)
> 
> This one should be sufficient. No further files or input is necessary, it
> seems that the problem lies in the combination of inheriting derived types,
> allocatables and pointers. All the fun.

You do like to stress the language and compilers, do you? :-)

However, this last reproducer appears to have something different -
it segfaults with released gfortran 8 and with or without the
patch we are looking at.

Also, the compiler warns

pointer_assign_16.f90:195:0:

  195 |     if (associated (global)) then
      | 
Warnung: »global._data« wird in dieser Funktion uninitialisiert verwendet
[-Wuninitialized]
pointer_assign_16.f90:195:8:

  195 |     if (associated (global)) then
      |        ^
Warnung: »global._data« wird in dieser Funktion uninitialisiert verwendet
[-Wuninitialized]


I'll look at this tomorrow, when I don't have to do may day job.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #36 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Hm, I hope I didn't change the flavor of the bug, but you can cross-check with
the very first reproducer which contains our code more or less unchanged
(except for the build setup with autotools etc.).

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

--- Comment #37 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #36)
> Hm, I hope I didn't change the flavor of the bug, but you can cross-check
> with the very first reproducer which contains our code more or less
> unchanged (except for the build setup with autotools etc.).

Since your latest reproducer fails with any version I tried, I suspect
you may have deleted the one line too many. Hmm, checking... yes, this is the
case.

  subroutine rt_data_activate (local)
    class(rt_data_t), intent(inout), target :: local
    class(rt_data_t), pointer :: global
    if (associated (global)) then
       local%logfile = global%logfile
       local%pn = global%pn
    end if
  end subroutine rt_data_activate

A previous version has

    global => local%context

as the first executable statement but that is rejected now;
and if I comment out the whole body of the subroutine,
there is no error.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #38 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 48426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48426&action=edit
Correct 'final' final reproducer

Indeed,
rt_data_t should have an additional
component
type(rt_data_t), pointer :: context => null

subroutine rt_data_init
should contain the additional line
local%context => global

and 
subroutine rt_data_activate 
should contain the additional line
global => local%context

Sorry about that.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[juergen.reuter at desy dot de]

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

--- Comment #39 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I submitted a corrected 'final' reproducer, sorry about that. Was too tired
yesterday.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

--- Comment #40 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Yes, that test case works.

Thanks a lot for putting in all the effort!

Because we need -fsanitize=address to reliably detect this
bug, I have proposed

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/544975.html

which introduces such a gfortran.dg/asan directory where
this can be tested.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[cvs-commit at gcc dot gnu.org]

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

--- Comment #41 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Thomas Kथà¤nig
<tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:cb2c76c8b156c6d8541ddb3aa894568a2de3b02b

commit r9-8557-gcb2c76c8b156c6d8541ddb3aa894568a2de3b02b
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Fri May 1 14:45:56 2020 +0200

    Revert patch for PR fortran/93956.

    2020-04-27  Thomas Koenig  <tkoenig@gcc.gnu.org>

                PR fortran/93956
                PR fortran/94788
                * expr.c (gfc_check_pointer_assign): Revert patch for PR 93956.
                * interface.c: Likewise.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[cvs-commit at gcc dot gnu.org]

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

--- Comment #42 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Thomas Kथà¤nig
<tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:b92bb10248a8f99cecf71a54c56bd4d8c75a322f

commit r8-10228-gb92bb10248a8f99cecf71a54c56bd4d8c75a322f
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Fri May 1 14:45:56 2020 +0200

    Revert patch for PR fortran/93956.

    2020-04-27  Thomas Koenig  <tkoenig@gcc.gnu.org>

                PR fortran/93956
                PR fortran/94788
                * expr.c (gfc_check_pointer_assign): Revert patch for PR 93956.
                * interface.c: Likewise.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[cvs-commit at gcc dot gnu.org]

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

--- Comment #43 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Kथà¤nig <tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:116784bbde9ed391393320d936ae2fff37442779

commit r11-25-g116784bbde9ed391393320d936ae2fff37442779
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Sat May 2 17:30:01 2020 +0200

    Add asan subdirectory for gfortran.dg.

    Because the test case for PR 94788 requires -fsanitize=address to expose
    the double free, I have created a subdirectory under gfortran.dg
    where such test cases can go.

    I have tested this with

    make check-fortran RUNTESTFLAGS="asan.exp=*"

    and it works; with a compiler that introduces the double free bug
            into the test case, the result is as expected

    2020-05-02  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/94788
            * gfortran.dg/asan: New directory.
            * gfortran.dg/asan/asan.exp: New file.
            * gfortran.dg/asan/pointer_assign_16.f90: New test case.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[cvs-commit at gcc dot gnu.org]

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

--- Comment #44 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:6abe1c3084798d3e5f32926c352643e557073e01

commit r11-27-g6abe1c3084798d3e5f32926c352643e557073e01
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sat May 2 12:46:44 2020 -0700

    gfortran: Get asan library from TEST_ALWAYS_FLAGS

    Update gfortran_target_compile to get the newly built asan library from
    TEST_ALWAYS_FLAGS to avoid:

    /usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
    /usr/bin/ld: cannot find -lasan
    collect2: error: ld returned 1 exit status
    compiler exited with status 1
    FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O0  (test
for excess errors)

            PR fortran/94788
            * lib/gfortran.exp (gfortran_target_compile): Get asan library
            from TEST_ALWAYS_FLAGS.

[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #45 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Fixed on all branches.