You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Henry Zongaro (JIRA)" <xa...@xml.apache.org> on 2005/06/15 16:49:47 UTC

[jira] Updated: (XALANJ-2146) Byte code generated by XSLTC contains backwards branch when uninitialized object is on stack

     [ http://issues.apache.org/jira/browse/XALANJ-2146?page=all ]

Henry Zongaro updated XALANJ-2146:
----------------------------------

    Description: 
Section 4.3.4 of the Java Virtual Machine Specification, 2nd Edition, places the following restriction on Java byte code:

«A valid instruction sequence must not have an uninitialized object on the operand stack or in a local variable during a backwards branch, or in a local variable in code protected by an exception handler or a finally clause. Otherwise, a devious piece of code might fool the verifier into thinking it had initialized a class instance when it had, in fact, initialized a class instance created in a previous pass through a loop.»

There are a number of places where XSLTC generates code that violates this requirement; a strict implementation of the verification process described by the JVM specification would detect the invalid byte code.  Most popular JVMs do not seem to detect this problem - presumably because their verification is less stringent - but this is a problem that needs to be fixed.

See copy16.xsl for an example of the offending code sequence.  The id function seems to be involved in all cases that pose a problem.

  was:
Section 4.3.4 of the Java Virtual Machine Specification, 2nd Edition, places the following restriction on Java byte code:

«A valid instruction sequence must not have an uninitialized object on the operand stack or in a local variable during a backwards branch, or in a local variable in code protected by an exception handler or a finally clause. Otherwise, a devious piece of code might fool the verifier into thinking it had initialized a class instance when it had, in fact, initialized a class instance created in a previous pass through a loop.»

There are a number of places where XSLTC generates code that violates this requirement; a strict implementation of the verification process described by the JVM specification would detect the invalid byte code.  Most popular JVMs do not seem to detect this problem - presumably because their verification is less stringent - but this is a problem that needs to be fixed.


> Byte code generated by XSLTC contains backwards branch when uninitialized object is on stack
> --------------------------------------------------------------------------------------------
>
>          Key: XALANJ-2146
>          URL: http://issues.apache.org/jira/browse/XALANJ-2146
>      Project: XalanJ2
>         Type: Bug
>   Components: XSLTC
>     Versions: CurrentCVS
>     Reporter: Henry Zongaro
>     Assignee: Henry Zongaro
>     Priority: Critical
>      Fix For: 2.7.0-future-release

>
> Section 4.3.4 of the Java Virtual Machine Specification, 2nd Edition, places the following restriction on Java byte code:
> «A valid instruction sequence must not have an uninitialized object on the operand stack or in a local variable during a backwards branch, or in a local variable in code protected by an exception handler or a finally clause. Otherwise, a devious piece of code might fool the verifier into thinking it had initialized a class instance when it had, in fact, initialized a class instance created in a previous pass through a loop.»
> There are a number of places where XSLTC generates code that violates this requirement; a strict implementation of the verification process described by the JVM specification would detect the invalid byte code.  Most popular JVMs do not seem to detect this problem - presumably because their verification is less stringent - but this is a problem that needs to be fixed.
> See copy16.xsl for an example of the offending code sequence.  The id function seems to be involved in all cases that pose a problem.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org