diff mbox series

PR fortran/96381 - invalid read in gfc_find_derived_vtab

Message ID trinity-4fa6f356-db34-4fbf-8eaf-de069b33adfd-1609517673193@3c-app-gmx-bs09
State New
Headers show
Series PR fortran/96381 - invalid read in gfc_find_derived_vtab | expand

Commit Message

Harald Anlauf Jan. 1, 2021, 4:14 p.m. UTC
Dear all,

happy New Year!

The testcase committed with the fix for PR93337 uncovered a latent issue
with an invalid read that was discovered with an ASAN instrumented compiler
but which could also be verified by running f951 under valgrind.

According to my gdb sessions the invalid read happens when processing a
statement that refers to a rejected declaration of a CLASS instance.
We simply should not try to look up the vtab entry in such cases.

All variations of the testcase gfortran.dg/pr93337.f90 that I tried on
x86_64-pc-linux-gnu with the patch below appeared to behave clean running
f951 under valgrind.

Regtested on x86_64-pc-linux-gnu.

OK for master?  Since the fix for PR93337 was applied to 9/10/11, I intend
to backport after suitable waiting time.

Thanks,
Harald


PR fortran/96381 - invalid read in gfc_find_derived_vtab

An invalid declaration of a CLASS instance can lead to an internal state
with inconsistent attributes during parsing that needs to be handled with
sufficient care when processing subsequent statements.  Avoid a lookup of
the vtab entry for such cases.

gcc/fortran/ChangeLog:

	* class.c (gfc_find_vtab): Add check on attribute is_class.

Comments

Paul Richard Thomas Jan. 1, 2021, 5:07 p.m. UTC | #1
Hi Harald,

It looks good to me - OK for master and backporting.

Thanks

Paul


On Fri, 1 Jan 2021 at 16:14, Harald Anlauf via Fortran <fortran@gcc.gnu.org>
wrote:

> Dear all,
>
> happy New Year!
>
> The testcase committed with the fix for PR93337 uncovered a latent issue
> with an invalid read that was discovered with an ASAN instrumented compiler
> but which could also be verified by running f951 under valgrind.
>
> According to my gdb sessions the invalid read happens when processing a
> statement that refers to a rejected declaration of a CLASS instance.
> We simply should not try to look up the vtab entry in such cases.
>
> All variations of the testcase gfortran.dg/pr93337.f90 that I tried on
> x86_64-pc-linux-gnu with the patch below appeared to behave clean running
> f951 under valgrind.
>
> Regtested on x86_64-pc-linux-gnu.
>
> OK for master?  Since the fix for PR93337 was applied to 9/10/11, I intend
> to backport after suitable waiting time.
>
> Thanks,
> Harald
>
>
> PR fortran/96381 - invalid read in gfc_find_derived_vtab
>
> An invalid declaration of a CLASS instance can lead to an internal state
> with inconsistent attributes during parsing that needs to be handled with
> sufficient care when processing subsequent statements.  Avoid a lookup of
> the vtab entry for such cases.
>
> gcc/fortran/ChangeLog:
>
>         * class.c (gfc_find_vtab): Add check on attribute is_class.
>
>
diff mbox series

Patch

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 5677d920239..783e4c7354b 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -2906,7 +2906,9 @@  gfc_find_vtab (gfc_typespec *ts)
     case BT_DERIVED:
       return gfc_find_derived_vtab (ts->u.derived);
     case BT_CLASS:
-      if (ts->u.derived->components && ts->u.derived->components->ts.u.derived)
+      if (ts->u.derived->attr.is_class
+	  && ts->u.derived->components
+	  && ts->u.derived->components->ts.u.derived)
 	return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived);
       else
 	return NULL;