harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-2088) [drlvm] [verifier] Verifier allows type inference to fail on values recieved by pop instruction
Date Fri, 06 Apr 2007 12:36:16 GMT
Ok, I read carefully and see that the fix should be improved. Working.

On 4/6/07, Alexei Fedotov (JIRA) <jira@apache.org> wrote:
>
>    [ https://issues.apache.org/jira/browse/HARMONY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487227
]
>
> Alexei Fedotov commented on HARMONY-2088:
> -----------------------------------------
>
> Fixed as a part of HARMONY-3225
>
> @@ -580,12 +565,20 @@ vf_check_entry_types( vf_MapEntry_t * en
>         }
>         break;
>     case SM_WORD:
> -        // check not strict correspondence types
> -        if( entry1->m_type >= SM_LONG_LO ) {
> -            return VER_ErrorDataFlow;
> -        }
> +        // pop gets any single word
> +        switch (entry1->m_type) {
> +        case SM_INT:
> +        case SM_FLOAT:
> +        case SM_NULL:
> +            break;
> +        case SM_REF:
> +        // case SM_UNINITIALIZED:
> +        case SM_RETURN_ADDR:
>         *need_copy = true;
>         break;
> +        default:
> +            return VER_ErrorDataFlow;
> +        }
>     case SM_WORD2_LO:
>         // check not strict correspondence types
>         if( entry1->m_type >= SM_LONG_HI ) {
>
> > [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.
>
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message