VerifyError: Bad type on operand stack

[Tal Liron]

Hi Attila, I am attaching the file. I didn't attach it originally, 
because I thought it would be impossible for you to test: it is normally 
run from within an embedded environment based on Scripturian/Sincerity. 
However, I am happy say that i tried anyway and the exact same exception 
is reproducible even with jjs. Note that "jjs --compile-only" completes 
without error.

-Tal


On 09/13/2013 02:09 PM, Attila Szegedi wrote:
> 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.