VerifyError: Bad type on operand stack

[Attila Szegedi]

So you have a file named javascript_nashorn.javascript, I presume. Any chance you can give it to us? We will probably be able to reproduce from it. Alternatively, try to use "jjs --compile-only <filename>", see if it fails, and then try to cut it down to a minimal failing version. 

Attila. 

Sent from my iPhone

On 2013.09.12., at 20:39, Tal Liron <tal.liron at threecrickets.com> wrote:

> Thanks. Unfortunately I can't isolate specific JavaScript code in this instance for you to reproduce, because I'm trying to run a rather large application that works in Rhino and I don't know what specifically causes the failure. The stack trace doesn't tell me much, but it might help you. Would be more than happy to help you debug.
> 
> Version (the new early release of the JDK):
> 
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b106)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b48, mixed mode)
> 
> Exception:
> 
> java.lang.VerifyError: Bad type on operand stack
> Exception Details:
>  Location:
> jdk/nashorn/internal/scripts/Script$javascript_nashorn.javascript(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; @101: invokevirtual
>  Reason:
>    Type 'java/lang/Object' (current frame, stack[0]) is not assignable to 'jdk/nashorn/internal/runtime/ScriptObject'
>  Current Frame:
>    bci: @101
>    flags: { }
>    locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', '[Ljava/lang/Object;', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject', top, 'jdk/nashorn/internal/objects/NativeArray', 'java/lang/Object', 'java/util/Iterator' }
>    stack: { 'java/lang/Object', integer }
>  Bytecode:
>    0000000: 2ab6 0018 3a04 2c2a 04b8 007e 4eb2 006b
>    0000010: 3a07 08b8 0048 5904 1904 ba00 8100 0053
>    0000020: b800 4e3a 062d 03b6 0085 ba00 8800 004e
>    0000030: 2db8 008c 3a08 a700 2319 08b9 0092 0100
>    0000040: 3a07 1906 59ba 0095 0000 5f2d 1907 ba00
>    0000050: 9900 00ba 009a 0000 5719 08b9 009e 0100
>    0000060: 9aff d92d 03b6 0085 ba00 a100 0059 ba00
>    0000070: a400 005f 1906 ba00 9a00 0057 b200 6bb0
>    0000080:
>  Stackmap Table:
> full_frame(@57,{Object[#20],Object[#117],Object[#171],Object[#117],Object[#115],Top,Object[#173],Object[#117],Object[#142]},{})
>    same_frame(@89)
> 
>    at java.lang.Class.getDeclaredFields0(Native Method)
>    at java.lang.Class.privateGetDeclaredFields(Class.java:2476)
>    at java.lang.Class.getDeclaredField(Class.java:1975)
>    at jdk.nashorn.internal.codegen.Compiler$2.run(Compiler.java:417)
>    at jdk.nashorn.internal.codegen.Compiler$2.run(Compiler.java:413)
>    at java.security.AccessController.doPrivileged(Native Method)
>    at jdk.nashorn.internal.codegen.Compiler.install(Compiler.java:413)
>    at jdk.nashorn.internal.codegen.Compiler.install(Compiler.java:447)
>    at jdk.nashorn.internal.runtime.Context.compile(Context.java:888)
>    at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:844)
>    at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:387)
> 
> 
> On 09/13/2013 02:24 AM, Jim Laskey (Oracle) wrote:
>> We're hoping to have the new bug tracking system online soon, but in the meantime to can send an e-mail here.  Describe the problem, a "small" test case that reproduces the problem (we generally don't isolate bugs) and how to reproduce the problem.
>