[jira] Created: (JIBX-239) JiBX-instrumented classes have invalid bytecode

JiBX-instrumented classes have invalid bytecode
-----------------------------------------------

                 Key: JIBX-239
                 URL: http://jira.codehaus.org/browse/JIBX-239
             Project: JiBX
          Issue Type: Bug
          Components: Generator Tools
    Affects Versions: JiBX 1.1.6
            Reporter: Aaron Gaalswyk


When you instrument a class using a JiBX binding file and the JiBX binding compiler, the bytecode magic--presumably done mostly with bcel--includes adding a new method like JiBX_jibx_binding_unmarshal_1_0 (or for a named binding, "JiBX_[something]_unmarshal_1_0").  We ran into a problem wherein if that bytecode is further massaged by some other application, the resultant class throws a VerifyError when loaded, like this:

Caused by: java.lang.VerifyError: (class: com/foo/jibx/SomethingRequest, method: JiBX_jibx_binding_unmarshal_1_0 signature: (Lorg/jibx/runtime/impl/UnmarshallingContext;)Lcom/foo/jibx/SomethingRequest;) Inconsistent stack height
        at java.lang.Class.getDeclaredFields0(Native Method)
        at java.lang.Class.privateGetDeclaredFields(Class.java(Compiled Code))
        at java.lang.Class.getDeclaredField(Class.java:1328)
        at org.jibx.runtime.BindingDirectory.getBindingList(BindingDirectory.java:77)
        at org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:211)
        at org.springframework.oxm.jibx.JibxMarshaller.afterPropertiesSet(JibxMarshaller.java:139)

In our case, the second program to come along to update already-Jibx-instrumented bytecode was a Compuware Vantage Analyzer.  The response from Compuware's engineers was:

"These methods leave a non empty stack when returning to the caller. The JVM normally tolerates this condition and simply clears the current stack and reinstates the caller's stack frame. However, when this code is wrapped with try/catch/finally, it would result in a non empty stack at return time in normal execution and an empty stack at return time when an exception occurs. This is a violation of specification, hence the VerifyError."

So, can something be done about these methods returning with a non-empty stack?


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

       

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
jibx-devs mailing list
jibx-devs@...
https://lists.sourceforge.net/lists/listinfo/jibx-devs

     [ http://jira.codehaus.org/browse/JIBX-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Sosnoski updated JIBX-239:
---------------------------------

      Assignee: Dennis Sosnoski
    Issue Type: Improvement  (was: Bug)
       Summary: JiBX-instrumented classes can cause problems when adding other instrumentation  (was: JiBX-instrumented classes have invalid bytecode)

I've just checked the JVM specification, and I can find no requirement that bytecode clear values from the stack before returning from a method. It's probably true that bytecode generated by the Java compiler does this - but the rules for verification are spelled out in the JVM specification, and tools need to adhere to those rules, rather than to the Java compiler output conventions.

I'm leaving this as an improvement request for JiBX (after changing the title to be accurate), and will address it when I restructure the code generation for JiBX 2.0 - but as far as I can see the error is actually in the other tool you are using, not in JiBX. If the engineers for the other tool are able to give some justification for calling this an error on the part of JiBX (in terms of the JVM specification), I'll restore the title and return it to bug status.

> JiBX-instrumented classes can cause problems when adding other instrumentation
> ------------------------------------------------------------------------------
>
>                 Key: JIBX-239
>                 URL: http://jira.codehaus.org/browse/JIBX-239
>             Project: JiBX
>          Issue Type: Improvement
>          Components: Generator Tools
>    Affects Versions: JiBX 1.1.6
>            Reporter: Aaron Gaalswyk
>            Assignee: Dennis Sosnoski
>
> When you instrument a class using a JiBX binding file and the JiBX binding compiler, the bytecode magic--presumably done mostly with bcel--includes adding a new method like JiBX_jibx_binding_unmarshal_1_0 (or for a named binding, "JiBX_[something]_unmarshal_1_0").  We ran into a problem wherein if that bytecode is further massaged by some other application, the resultant class throws a VerifyError when loaded, like this:
> Caused by: java.lang.VerifyError: (class: com/foo/jibx/SomethingRequest, method: JiBX_jibx_binding_unmarshal_1_0 signature: (Lorg/jibx/runtime/impl/UnmarshallingContext;)Lcom/foo/jibx/SomethingRequest;) Inconsistent stack height
>         at java.lang.Class.getDeclaredFields0(Native Method)
>         at java.lang.Class.privateGetDeclaredFields(Class.java(Compiled Code))
>         at java.lang.Class.getDeclaredField(Class.java:1328)
>         at org.jibx.runtime.BindingDirectory.getBindingList(BindingDirectory.java:77)
>         at org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:211)
>         at org.springframework.oxm.jibx.JibxMarshaller.afterPropertiesSet(JibxMarshaller.java:139)
> In our case, the second program to come along to update already-Jibx-instrumented bytecode was a Compuware Vantage Analyzer.  The response from Compuware's engineers was:
> "These methods leave a non empty stack when returning to the caller. The JVM normally tolerates this condition and simply clears the current stack and reinstates the caller's stack frame. However, when this code is wrapped with try/catch/finally, it would result in a non empty stack at return time in normal execution and an empty stack at return time when an exception occurs. This is a violation of specification, hence the VerifyError."
> So, can something be done about these methods returning with a non-empty stack?

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

       

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
jibx-devs mailing list
jibx-devs@...
https://lists.sourceforge.net/lists/listinfo/jibx-devs

     [ http://jira.codehaus.org/browse/JIBX-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Sosnoski updated JIBX-239:
---------------------------------

    Component/s:     (was: Generator Tools)
                 core

> JiBX-instrumented classes can cause problems when adding other instrumentation
> ------------------------------------------------------------------------------
>
>                 Key: JIBX-239
>                 URL: http://jira.codehaus.org/browse/JIBX-239
>             Project: JiBX
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: JiBX 1.1.6
>            Reporter: Aaron Gaalswyk
>            Assignee: Dennis Sosnoski
>
> When you instrument a class using a JiBX binding file and the JiBX binding compiler, the bytecode magic--presumably done mostly with bcel--includes adding a new method like JiBX_jibx_binding_unmarshal_1_0 (or for a named binding, "JiBX_[something]_unmarshal_1_0").  We ran into a problem wherein if that bytecode is further massaged by some other application, the resultant class throws a VerifyError when loaded, like this:
> Caused by: java.lang.VerifyError: (class: com/foo/jibx/SomethingRequest, method: JiBX_jibx_binding_unmarshal_1_0 signature: (Lorg/jibx/runtime/impl/UnmarshallingContext;)Lcom/foo/jibx/SomethingRequest;) Inconsistent stack height
>         at java.lang.Class.getDeclaredFields0(Native Method)
>         at java.lang.Class.privateGetDeclaredFields(Class.java(Compiled Code))
>         at java.lang.Class.getDeclaredField(Class.java:1328)
>         at org.jibx.runtime.BindingDirectory.getBindingList(BindingDirectory.java:77)
>         at org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:211)
>         at org.springframework.oxm.jibx.JibxMarshaller.afterPropertiesSet(JibxMarshaller.java:139)
> In our case, the second program to come along to update already-Jibx-instrumented bytecode was a Compuware Vantage Analyzer.  The response from Compuware's engineers was:
> "These methods leave a non empty stack when returning to the caller. The JVM normally tolerates this condition and simply clears the current stack and reinstates the caller's stack frame. However, when this code is wrapped with try/catch/finally, it would result in a non empty stack at return time in normal execution and an empty stack at return time when an exception occurs. This is a violation of specification, hence the VerifyError."
> So, can something be done about these methods returning with a non-empty stack?

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

       

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
jibx-devs mailing list
jibx-devs@...
https://lists.sourceforge.net/lists/listinfo/jibx-devs