[Bug fortran/99529] libgfortran I/O: Data races related to new unit / new unit calls for I/O to strings

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Missed to add a PR fortran/99529, hence, the commit did not show up:

r11-7647-ga6e9633ccb593937fceec67fafc2afe5d518d735

commit a6e9633ccb593937fceec67fafc2afe5d518d735
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri Mar 12 16:31:32 2021 +0100

    Fortran: Fix libgfortran I/O race with newunit_free [PR99529]

    libgfortran/ChangeLog:

            * io/transfer.c (st_read_done_worker, st_write_done_worker):
            Call unlock_unit here, add unit_lock lock around newunit_free call.
            (st_read_done, st_write_done): Only call unlock_unit when not
            calling the worker function.
            * io/unit.c (set_internal_unit): Don't reset the unit_number
            to the same number as this cause race warnings.

 * * *

Committed patch was the revised version
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566600.html

Martin (who reported the issue + helped debugging it) wrote in one of the email
threads:
"BTW, I will do some more tests, but it looks like the patch fixes
the memory corruption issue."

Thus, hopefully, this issue is fixed for good. Thanks to all involved for the
help!

→ Close as FIXED (on mainline, GCC 11).