From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 0D17838708D1; Thu, 11 Mar 2021 09:07:25 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D17838708D1
From: "mscfd at gmx dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/99529] libgfortran I/O: Data races related to new unit
 / new unit calls for I/O to strings
Date: Thu, 11 Mar 2021 09:07:24 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mscfd at gmx dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-99529-4-edB3AicPSa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99529-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99529-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 09:07:25 -0000

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

--- Comment #4 from martin <mscfd at gmx dot net> ---
Ok, here is another suspicious data race in unit.c (backtrace from helgrind=
):

=3D=3D7831=3D=3D Possible data race during read of size 4 at 0x5DE4620 by t=
hread #296
=3D=3D7831=3D=3D Locks held: 1, at address 0x2EE5D00
=3D=3D7831=3D=3D    at 0x10067CB: get_gfc_unit (unit.c:336)
=3D=3D7831=3D=3D    by 0x10071DB: _gfortrani_get_unit (unit.c:556)
=3D=3D7831=3D=3D    by 0x10050DC: data_transfer_init (transfer.c:2851)
...
=3D=3D7831=3D=3D=20
=3D=3D7831=3D=3D This conflicts with a previous write of size 4 by thread #3
=3D=3D7831=3D=3D Locks held: 1, at address 0x5DE4700
=3D=3D7831=3D=3D    at 0x10069F4: _gfortrani_set_internal_unit (unit.c:459)
=3D=3D7831=3D=3D    by 0x10071EC: _gfortrani_get_unit (unit.c:557)
=3D=3D7831=3D=3D    by 0x10050DC: data_transfer_init (transfer.c:2851)

There seems to be a conflicting access to "unit_cache[c]->unit_number",
set_internal_unit does not hold UNIT_LOCK.

I cannot observe this in the simple testcase, but in the real code at the r=
ight
place where I suspect the write-caused memory corruption.

(Just in case line numbers have changed:
unit.c:336:     if (unit_cache[c] !=3D NULL && unit_cache[c]->unit_number =
=3D=3D n)
unit.c:556:  iunit->unit_number =3D dtp->common.unit;
)=