[Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]
Jerry DeLisle
jvdelisle@charter.net
Fri Mar 12 01:35:47 GMT 2021
Looks good Tobias, OK,
Odd about that line in set_internal_unit. Probably leftover from a
copy/paste. I see in comment #5 of the PR that you mentioned trying the
assert to make sure it is useless code.
Thanks for the patch,
Jerry
On 3/11/21 2:38 AM, Tobias Burnus wrote:
> Revised version – the previous had a lock inversion, which could lead
> to a deadlock, found by -fsanitize=thread. See transfer.c for the
> changes.
>
> OK?
>
> Tobias
>
> On 11.03.21 10:42, Tobias Burnus wrote:
>> Hi all,
>>
>> as found by Martin (thanks!) there is a race for newunit_free.
>> While that call is within the unitlock for the calls in io/unit.c,
>> the call in transfer.c did not use locks.
>>
>> Additionally,
>> unit = get_gfc_unit (dtp->common.unit, do_create);
>> set_internal_unit (dtp, unit, kind);
>> gets first the unit (with proper locking when using the unit number
>> dtp->common.unit) but then in set_internal_unit it re-sets the
>> unit number to the same number without locking. That causes
>> race warnings and if the assignment is not atomic it is a true race.
>>
>> OK for mainline? What about GCC 10?
>>
>> As Martin notes in the email thread and in the PR there are more
>> race warnings (and likely true race issues).
>>
>> Tobias
>>
More information about the Fortran
mailing list