harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-1688) [DRLVM] Jitrino.OPT crashes on ClassTest
Date Mon, 09 Oct 2006 07:40:20 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-1688?page=comments#action_12440821 ] 
            
Alexey Varlamov commented on HARMONY-1688:
------------------------------------------

This testcase appears to be an abundant fountain of issues :) So far I found the following:
1) The testcase effectively disables unprivileged classloading of system classes and thus
implicitly checks how the VM under test handles requests to already loaded classes (in application
security context). The DRLVM only caches internally a set of defined classes per classloader
and relies on Java classes in obtaining initiated classes of any classloader. Anytime the
system classloader is asked to loadClass(), it first tries to checkPackageAccess() and falls
into recursion. That is why we get ClassCircularityError on interpreter and what provokes
SIGSEGV in Jitrino.OPT.
2) If we overcome the issue above, the testcase enforces somewhat stronger limitation: AccessController.checkPermission()
should never lead to nested call for SecurityManager.checkPermission(), otherwise we have
recursion again. I guess if we slightly hack the environment of this testcase (without changing
testing logic itself) e.g. to use custom security policy provider, we'll be able to reproduce
endless recursion on RI too. The DRLVM is more vulnerable to this due to it's pure-Java ACC
impl peculiarities, it fails even with the default policy.

Actually both issues are not justified with any specification I'm aware of, and both can be
solved either via fixing the test or JRE impl (either VM and/or classes). So the question
is: which solutions are more appropriate? I personally feel that the first issue should be
fixed in VM (because it is quite likely to reoccur as real-world compatibility issue). And,
strictly speaking, the second issue has no complete solution in JRE. 

> [DRLVM] Jitrino.OPT crashes on ClassTest
> ----------------------------------------
>
>                 Key: HARMONY-1688
>                 URL: http://issues.apache.org/jira/browse/HARMONY-1688
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: debug gcc 3.3.3 DRLVM r452709
> SLES 9 32-bit SP2; CPU 2xXeon x64 (Clovertown B, 4cores)
>            Reporter: Alexey Varlamov
>
> The Jitrino.OPT fails with segmentation fault on org.apache.harmony.luni.tests.java.lang.ClassTest.

> To reproduce:
> > java -cp junit.jar:$classlib/modules/luni/bin/test:$classlib/deploy/build/test/support.jar
junit.textui.TestRunner org.apache.harmony.luni.tests.java.lang.ClassTest
> SIGSEGV in VM code.
> Stack trace:
> 	1: Jitrino::TypeManager::toInternalType(Jitrino::Type*) (??:-1)
> 	2: Jitrino::JavaLabelPrepass::JavaLabelPrepass(Jitrino::MemoryManager&, Jitrino::TypeManager&,
Jitrino::MemoryManager&, Jitrino::MethodDesc&, Jitrino::CompilationInterface&,
Jitrino::Opnd**) (??:-1)
> 	3: Jitrino::alloc_arena(Jitrino::Arena*, unsigned int) (??:-1)
> 	4: Jitrino::alloc_arena(Jitrino::Arena*, unsigned int) (??:-1)
> 	5: ?? (??:-1)
> 	6: Jitrino::MemoryManager::alloc(unsigned int) (??:-1)
> 	7: Jitrino::Tree::computeNodeOrder(Jitrino::TreeNode*, unsigned int&, unsigned int&)
(??:-1)
> 	8: ?? (??:-1)
> 	9: ?? (??:-1)
> 	10: Jitrino::JavaByteCodeTranslator::JavaByteCodeTranslator(Jitrino::CompilationInterface&,
Jitrino::MemoryManager&, Jitrino::IRBuilder&, Jitrino::ByteCodeParser&, Jitrino::MethodDesc&,
Jitrino::TypeManager&, Jitrino::JavaFlowGraphBuilder&) (??:-1)
> 	11: ?? (0015d890:15)
> 	12: Jitrino::MemoryManager::alloc(unsigned int) (??:-1)
> 	13: ?? (??:-1)
> 	14: Jitrino::JavaFlowGraphBuilder::JavaFlowGraphBuilder(Jitrino::MemoryManager&,
Jitrino::IRBuilder&) (??:-1)
> 	15: method_get_byte_code_addr (/nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/vmcore/src/class_support/C_Interface.cpp:365)
> 	16: ?? (??:-1)
> 	17: ?? (??:-1)
> 	18: Jitrino::JavaTranslator::translateMethod(Jitrino::CompilationInterface&, Jitrino::MethodDesc&,
Jitrino::IRBuilder&) (??:-1)
> <end of stack trace>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message