harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2088) [drlvm] [verifier] Verifier allows type inference to fail on values recieved by pop instruction
Date Wed, 18 Apr 2007 16:33:15 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489812
] 

Alexei Fedotov commented on HARMONY-2088:
-----------------------------------------

Please close the bug since it is fixed as a part of H-3225 bug. A regression test is committed
as a part of that bug as well.

> [drlvm] [verifier] Verifier allows type inference to fail on values recieved by pop instruction
> -----------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-2088
>                 URL: https://issues.apache.org/jira/browse/HARMONY-2088
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: any
>            Reporter: Egor Pasko
>            Priority: Minor
>         Attachments: Test.j
>
>
> as specified in [1] :
> Verification by type inference must be supported by *all Java virtual machines*, except
those conforming to the JavaCard and J2ME CLDC profiles.
> as described later in [1] (under "Verification by type inference"):
> To merge two operand stacks, the number of values on each stack must be identical. The
types of values on the stacks must also be identical, except that differently typed reference
values may appear at corresponding places on the two stacks. In this case, the merged operand
stack contains a reference to an instance of the first common superclass of the two types.
Such a reference type always exists because the type Object is a superclass of all class and
interface types. If the operand stacks cannot be merged, verification of the method fails.
> However, DRLVMs verifier only checks that "Structural constraints" are met. In case of
unmergable types used only by pop instruction, verification passes. Consider the following
test:
> --------------------- begin Test.j ----------------------
> .class public Test
> .super java/lang/Object
> .method public static main([Ljava/lang/String;)V
> .limit stack 2
> .limit locals 3
>     iconst_0
>     iconst_0
>     ifne Label0
>     pop
>     fconst_0
> Label0:
>     pop
>     return
> .end method
> --------------------- end Test.j ----------------------
> to reproduce the failure:
> * obtain jasmin.jar from [2]
> * compile the test into a class file:
>    java -jar jasmin.jar Test.j
> * $HARMONY -Xem:opt Test
> with that you get it crashed:
> SIGSEGV in VM code.
> Stack trace:
>         1: Jitrino::JavaByteCodeTranslator::offset(unsigned int) (??:-1)
>         2: Jitrino::JavaByteCodeParserCallback::parseByteCode(unsigned char const*, unsigned
int) (??:-1)
>         3: Jitrino::JavaTranslator::translateMethod(Jitrino::CompilationInterface&,
Jitrino::MethodDesc&, Jitrino::IRBuilder&) (??:-1)
>         4: Jitrino::TranslatorSession::translate() (??:-1)
>         5: Jitrino::TranslatorSession::run() (??:-1)
>         6: Jitrino::runPipeline(Jitrino::CompilationContext*) (??:-1)
>         7: Jitrino::compileMethod(Jitrino::CompilationContext*) (??:-1)
>         8: Jitrino::Jitrino::CompileMethod(Jitrino::CompilationContext*) (??:-1)
>         9: JIT_compile_method_with_params (??:-1)
> [snip]
> that's because Jitrino.OPT cannot handle this kind of incorrect java bytecode. RI throws
VerifyError here. On Jitrino.JET the test does not crash the VM. 
> There are 2 issues here to look at:
> 1. Verifier allows the code that does not comply with the spec update [1]
> 2. Jitrino.OPT sometimes crashes on unverifiable bytecodes
> this issue describes (1). If you think that Jitrino.OPT should not crash on any bytecode
(which is (2)), feel free to file another issue for that. Crash-free translation is not easy
with incorrect bytecodes. May require a strong Java Translator refactoring.
> [1]  http://java.sun.com/docs/books/vmspec/2nd-edition/UpdatedClassFileFormat.pdf 
> [2]  http://jasmin.sourceforge.net/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message