From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 08036385043B for ; Thu, 11 Mar 2021 07:48:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 08036385043B Received: by mail-ej1-x62c.google.com with SMTP id mm21so44116826ejb.12 for ; Wed, 10 Mar 2021 23:48:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zPFY6NePS8EJ/vJLqnL25HjeNAdM1r1elm4/PsgHG6U=; b=lAHpCP0WgwMCjevcuHt7E8PZFJJA7ZWBbfQu5jBmxgyY6DhHS15JTkbeCj9MjHda/I +OAZxzj1Xz4ITkxFSbNlrrQ5Hqniie6b1i7P/guKLWuUhNZSf2S79rq2VVnuuozmMq8F whBnHV+Jey6Ibk2E8FI6Mb3bOPlA7DFvhonV6JQzskI0gzxqJr2rpKaTLnL4vAOgd7cH Bpe2o9ufvmX42Hm1BmYIhW86cZqyNB08pMben6Va003/zcGrR6+ZU5B4mNZV1N8fCiVj joudA9bnai0pAQzQ7wPyHE56cVoGV2JadTryvKBvuwpNfME4vkoii/6XQ31Cb79V5969 KZFg== X-Gm-Message-State: AOAM5309NKxCuqPzz0LVCN+qj4ZdyKXBkR3HavFbBFlOoqGHGem9Qqg4 91RfYiz3UcgVRWRIUPlCFQhsFJztGurpH/zyHxo= X-Google-Smtp-Source: ABdhPJw7yjPqfteQgJG9d+t17Mlt+QsKLrE4r1u356tkZjDeZaAPKpMAbmmxFIYEBjCfTwPJuuveQLWIE7kggEZG8vI= X-Received: by 2002:a17:906:f01:: with SMTP id z1mr1889618eji.235.1615448914149; Wed, 10 Mar 2021 23:48:34 -0800 (PST) MIME-Version: 1.0 References: <856aeaf7-defa-4797-a0e2-d4d5e07f5cc6@gmx.net> In-Reply-To: <856aeaf7-defa-4797-a0e2-d4d5e07f5cc6@gmx.net> From: Richard Biener Date: Thu, 11 Mar 2021 08:48:23 +0100 Message-ID: Subject: Re: To: mscfd Cc: "fortran@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 07:48:36 -0000 On Wed, Mar 10, 2021 at 8:39 PM mscfd via Fortran wro= te: > > > which version of gfortran, and which operating system? > I have seen this on two different Linux distros on x86 with a recently co= mpiled version, but also some time ago with an older gfortran 10 version. > > Using helgrind on a simple omp do loop with write to a character variable= , I get some possible data races in Libgfortran/io/unit.c. There a newunits= array is allocated and possibly reallocated in "newunit_alloc". According = to the lock outputs from helgrind I see that this routine is called even if= output into character variable is done. Now "newunit_alloc" uses a lock to= avoid having several thread all over the place. But newunit_free also writ= es to newunits array. And this routine does not obtain a lock itself (see c= omment in unit.c) So in theory it can happen that newunit_alloc reallocated= newunits, and newunit_free writes to it just at this time. As I also use 1= 8 threads the initial size of 16 does not suffice and reallocation does pro= bably indeed happen. > Also acces to newunit_lwi is not protected as well (and complained about = by helgrind). > > Could it be that the corresponding write routine in transfer.c which call= s newunit_free does not obtain the necessary lock. I cannot find it (which = does not count much). > > Any thoughts? try obtaining the locks around the places you figured and see if your problem goes away? > Martin