The old _Jv_InitClass problem is still present in 3.1 (patch included)

[Bryce McKinlay]

Martin Kahlert wrote:

>This was fixed some time ago for 3.0.*, but it is present in 3.1, too.
>(cf. http://gcc.gnu.org/ml/java-patches/2001-q3/msg00062.html 
>some later parts of the thread seem to be below 
> http://gcc.gnu.org/ml/java/2001-07/msg00173.html , too)
>
>The problem is:
>The compiler may generate calls to _Jv_IsAssignableFrom by its own (i.e. not
>all of its calls come from libjava).
>Then the classes may be uninitialized and my application segfaults.
>The fix is the same like it was in 3.0.*.
>It may be a performance problem, though.
>
>The other possibility is to ensure, that classes where _Jv_IsAssignableFrom
>or _Jv_IsInstanceOf is called on, are initialized.
>
I looked at this some more. Could you try this patch instead? I don't 
think its correct to initialize "target" just because its the subject of 
an instanceof or checkcast. If target is uninitialized, then there must 
be no instances of it, so the result must be 'false'.

regards

Bryce.

Index: natClass.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/lang/natClass.cc,v
retrieving revision 1.44
diff -u -r1.44 natClass.cc
--- natClass.cc 2001/06/05 09:46:36     1.44
+++ natClass.cc 2001/09/27 23:01:36
@@ -956,7 +956,7 @@
         return false;
       return true;
     }
-  else if (source->ancestors != NULL
+  else if (source->ancestors != NULL && target->ancestors != NULL
            && source->depth >= target->depth
           && source->ancestors[source->depth - target->depth] == target)
     return true;