[ http://issues.apache.org/jira/browse/XALANJ-2146?page=comments#action_12313700 ]
Henry Zongaro commented on XALANJ-2146: --------------------------------------- I've scanned classes of XSLTC that generated byte code and found the following have the potential to generate the offending sequence of code: AbsoluteLocationPath.java FilterExpr.java FilterParentPath.java FilteredAbsoluteLocationPath FunctionCall.java KeyCall.java ParentLocationPath.java Sort.java These classes create an object on the stack and then generate byte code for arguments to the constructor for that object. In all of these classes, the generated byte code could contain a backwards branch. The fix will be to first generate the byte code for the arguments that could contain backwards branches, store their values in temporary variables, create the object, load the values of the relevant arguments to the constructor from their temporaries and finally invoke the constructor. > 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. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
