On Wed, Mar 10, 2021 at 8:39 PM mscfd via Fortran <fortran@gcc.gnu.org> wrote: > > > which version of gfortran, and which operating system? > I have seen this on two different Linux distros on x86 with a recently > compiled 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 writes to > newunits array. And this routine does not obtain a lock itself (see comment > 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 18 > threads the initial size of 16 does not suffice and reallocation does > probably 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 calls > 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
