[jira] Updated: (HARMONY-2088) [drlvm][verifier] Verifier allows type inference to fail on values recieved by pop instruction

["Gregory Shimansky (JIRA)" <ji...@apache.org>]

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

Gregory Shimansky updated HARMONY-2088:
---------------------------------------

    Summary: [drlvm][verifier] Verifier allows type inference to fail on values recieved by pop instruction  (was: [drlvm] [verifier] Verifier allows type inference to fail on values recieved by pop instruction)

> [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.