JDK-8066221 : Fuzzing bug: Assertion error related to bytecode slots
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u60
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-12-01
  • Updated: 2015-06-04
  • Resolved: 2014-12-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40Fixed 9 b43Fixed
Related Reports
Cloners :  
JDK-8066222 - too strong assertion on function expression names
Cloners :  
JDK-8066220 - Fuzzing bug: MethodHandle bug (Object,Object) != (boolean)Object
Description
jjs> function f() { x3 = function x1(x3) { function (){} }; } f()
Exception in thread "main" java.lang.AssertionError: x3  (slot=-1 ) 1090
   at jdk.nashorn.internal.codegen.AssignSymbols.finalizeParameters(AssignSymbols.java:569)
   at jdk.nashorn.internal.codegen.AssignSymbols.leaveFunctionNode(AssignSymbols.java:849)
   at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:384)
   at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57)
   at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:47)
   at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:59)
   at jdk.nashorn.internal.ir.BinaryNode.accept(BinaryNode.java:347)
   at jdk.nashorn.internal.ir.ExpressionStatement.accept(ExpressionStatement.java:64)
   at jdk.nashorn.internal.ir.Node.accept(Node.java:265)
   at jdk.nashorn.internal.ir.Block.accept(Block.java:178)
Comments
There's two issues that need to be fixed here. They both concern naming of anonymous functions. Actually, either one fixes this issue, but both should be fixed for correctness: 1. When figuring out a default name for an anonymous function, function boundaries should hide the currently active default name. In the above example, when parser encounters "function x1", it should hide "x3" (the current default name by virtue of being a LHS identifier) so that "function(){}" doesn't see it and is thus not named "x3" but rather "L:1". 2. When assigning a default name for an anonymous function statement, it should be prefixed with anonymous function name prefix ("L:") so we don't give it a chance to clash with an already declared symbol. In the example above (assuming point 1 is not yet fixed), it would result in the innermost function being named "L:x3" instead of just "x3".
10-12-2014