Gary Benson wrote:
Jeroen Frijters wrote:
Guilhem Lavaux wrote:
This block is the loop:
at testSM$MySM.checkPermission (testSM.java:17)
at java.lang.SecurityManager.checkSecurityAccess
(SecurityManager.java:1011)
at java.security.Security.getProperty (Security.java:396)
at java.lang.SecurityManager$1.run (SecurityManager.java:1055)
at java.security.AccessController.doPrivileged
(AccessController.java:96)
at java.lang.SecurityManager.checkPackageList
(SecurityManager.java:1051)
at java.lang.SecurityManager.checkPackageAccess
(SecurityManager.java:920)
at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108)
at java.lang.ClassLoader.loadClass (ClassLoader.java:294)
The last loadClass is already loading java/security/Permission and
checkPermission needs to load java/security/Permission too. Maybe
it is also a SystemProperties trouble ?
This still looks like a VM bug to me. java/security/Permission
shouldn't be loaded through the application class loader, but the
boot class loader.
Isn't the boot class loader solely for java.lang?
FWIW I was able to push IBM's JRE into an infinite loop with this
test, so it would appear to be vulnerable to the same class of
problems even if not this actual problem.
Cheers,
Gary
For us the boot class loader principally loads the system class loader.
The reason why you see a loadClass is because we are using the system
class loader as built by java/lang/ClassLoader. This class loader loads
everything after boot normally. Looking into the VM state it _is_ the
case: the classes are loaded by ClassLoader$1 so implicit loading should
use this class loader also.
BTW, Gary your test triggers a really nasty VerifyError in kaffe so
maybe we also have to do some work here. Although it works fine on JDK
1.4.2.
Cheers,
Guilhem.
_______________________________________________
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
