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 Mon, 09 Apr 2007 14:31:32 GMT

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

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

Here goes a fix of the correct place. vf_merge_vectors() now reports "Type mismatch while
merging a stack map" instead of merging different types into SM_TOP value.

diff -pu 9/trunk/working_vm/vm/vmcore/src/verifier\ver_dataflow.cpp 91/trunk/working_vm/vm/vmcore/src/verifier\ver_dataflow.cpp
--- old/trunk/working_vm/vm/vmcore/src/verifier\ver_dataflow.cpp	Tue Mar 20 19:34:53 2007
+++ new/trunk/working_vm/vm/vmcore/src/verifier\ver_dataflow.cpp	Mon Apr 09 18:16:45 2007
@@ -207,21 +205,19 @@ vf_is_types_equal( vf_ValidType_t * type
 }                               // vf_is_types_equal
 
 /**
- * Function merges two vectors and saves result vector to first vector.
- * If first vector was changed, returns true, else - false.
+ * Merges two vectors and saves result vector to first vector.
+ * Sets <code>is_changed</code> to <code>true</code> if the first
vector was
+ * changed.
  */
-static inline bool
+static inline vf_Result
 vf_merge_vectors( vf_MapVector *first,  // first vector
                   vf_MapVectorHandle second,    // second vector
                   bool handler_flag,    // if merged node is handler
-                  vf_Context_t * ctex ) // verifier context
+                  bool &is_changed,     // true if the first vector was changed
+                  vf_Context *ctx )     // verification context
 {
-    bool is_changed = false;
-    vf_MapEntry_t zero = { 0 };
-
-    // check vectors parameters
-    assert( first->m_maxlocal == second->m_maxlocal );
-    assert( first->m_maxstack == second->m_maxstack );
+    is_changed = false;
+    vf_MapEntry zero = { 0 };
 
     // merge local variable vector
     unsigned index;
@@ -292,14 +288,14 @@ vf_merge_vectors( vf_MapVector *first,  
             continue;
         } else if( first->m_stack[index].m_type !=
                    second->m_stack[index].m_type ) {
-            // types are differ, reset result entry
-            first->m_stack[index] = zero;
-            is_changed = true;
+            // types differ, verification should fail
+            VF_REPORT( ctx, "Type mismatch while merging a stack map" );
+            return VER_ErrorDataFlow;
         } else if( first->m_stack[index].m_type == SM_REF ) {
             // reference types, merge them
[skipped]
@@ -281,7 +277,7 @@ vf_merge_vectors( vf_MapVector *first,  
     // check handler flag
     if( handler_flag ) {
         // no need merge stack for handler node
-        return is_changed;
+        return VER_OK;
     }
     // merge stack map vector
     assert( first->m_depth == second->m_depth );
@@ -319,41 +315,10 @@ vf_merge_vectors( vf_MapVector *first,  
             }
         }
     }
-    return is_changed;
+    return VER_OK;
 }                               // vf_merge_vectors
 
[skipped]
             // node's IN vector is valid, merge them
-            bool is_handler =
-                VF_TYPE_NODE_HANDLER == graph->GetNode( out_node )->m_type;
-            is_changed =
-                vf_merge_vectors( out_node_vector, in_node_vector, is_handler,
-                                  ctex );
+            bool is_handler = VF_NODE_HANDLER == outnode->m_type;
+            // FIXME for handler branches need to merge local variable maps for any
+            // FIXME instruction since a jump can happen anywhere
+
+            bool is_changed;
+            result = vf_merge_vectors( outnode_vector, innode_vector,
+                                       is_handler, is_changed, ctx );
+            if( VER_OK != result ) {
+                return result;
+            }
+
[skipped]

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