Am 28.05.20 um 21:58 schrieb Harald Anlauf:
The initial commit for this PR uncovered a latent issue with unit locking
in the Fortran run-time library. Add check for valid unit.
This only came up because Solaris, unlike Linux, links the pthreads
library by default, so it will not be found in a
Dear all,
> I think the second one is more robust - like you say, this may catch
> other cases. If we have that one, we don't need the first one.
to fix the fallout I've committed to master the following patch,
which I will backport to the affected branches (9/10):
PR fortran/95104 - Segfault
Hi Harald,
There are two possible fixes for this:
(1) guard the call to unlock_unit by:
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index cd51679ff46..296be0711a2 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -4508,7 +4508,8 @@ st_wait_async
The fix for
> PR fortran/95104 - Segfault on a legal WAIT statement
>
> Referencing a unit in a WAIT statement that has not been opened before
> resulted in a NULL pointer dereference. Check for this condition.
>
> 2020-05-26 Harald Anlauf
>
> libgfortran/
> PR libfortran/95104
>
Hi Thomas,
thanks for the hint:
> Von: "Thomas Koenig"
> Am 26.05.20 um 23:33 schrieb Harald Anlauf:
> > Will backport in a few days, when I figure out how to do it now.
>
> The way to backport now is to first run contrib/gcc-git-customization.sh
> from current master, and then change to the
Am 26.05.20 um 23:33 schrieb Harald Anlauf:
Committed as obvious.
The invalid NULL pointer dereference was discovered by Steve Kargl.
Will backport in a few days, when I figure out how to do it now.
Thanks for committing this.
The way to backport now is to first run
Committed as obvious.
The invalid NULL pointer dereference was discovered by Steve Kargl.
Will backport in a few days, when I figure out how to do it now.
Thanks,
Harald
PR fortran/95104 - Segfault on a legal WAIT statement
Referencing a unit in a WAIT statement that has not been opened
