Bad type on operand stack

[Andreas Joseph Krogh]

Hi all.

 

The following ERROR manifested itself after reloading classes using JRebel-6.2.2:

 

Using Scala-2.11.7 with the scalac-options -Ydelambdafy:method -Ybackend:GenBCode -target:jvm-1.8 and having scala-java8-compat_2.11 on the classpath (for compiling to java8-lambdas) I get this Error:

 

java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    scala/compat/java8/JFunction0$mcF$sp.apply()Ljava/lang/Object; @1: invokevirtual
  Reason:
    Type 'scala/compat/java8/JFunction0$mcF$sp' (current frame, stack[0]) is not assignable to 'com/zeroturnaround/reload/F'
  Current Frame:
    bci: @1
    flags: { }
    locals: { 'scala/compat/java8/JFunction0$mcF$sp' }
    stack: { 'scala/compat/java8/JFunction0$mcF$sp' }
  Bytecode:
    0x0000000: 2ab6 001e 9a00 1d2a b800 2459 2aa5 0013
    0x0000010: 59c1 0003 9900 0cc0 0003 b900 2601 00b0
    0x0000020: 572a b900 0101 00b8 0002 b0            
  Stackmap Table:
    same_locals_1_stack_item_frame(@32,Object[#4])
    same_frame(@33)

	sun.misc.Unsafe.defineAnonymousClass(Native Method)
	java.lang.invoke.InnerClassLambdaMetafactory.spinInnerClass(InnerClassLambdaMetafactory.java:324)
	java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite(InnerClassLambdaMetafactory.java:194)
	java.lang.invoke.LambdaMetafactory.altMetafactory(LambdaMetafactory.java:474)
	java.lang.invoke.CallSite.makeSite(CallSite.java:325)
	java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
	java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
	no.officenet.origo.frontend.lift.snippet.calendar.CalendarSnippetHelper$.getSummaryForCalendarEntries(CalendarSnippetHelper.scala:97)

 

Any idea if JRebel, the new GenBCode backend or java8-compat is to blame here?

 

Thanks.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

[Jason Zaugg]

On Thu, Aug 13, 2015 at 6:37 PM Andreas Joseph Krogh <and...@visena.com> wrote:

Hi all.

 

The following ERROR manifested itself after reloading classes using JRebel-6.2.2:

 

Using Scala-2.11.7 with the scalac-options -Ydelambdafy:method -Ybackend:GenBCode -target:jvm-1.8 and having scala-java8-compat_2.11 on the classpath (for compiling to java8-lambdas) I get this Error:

 

java.lang.VerifyError: Bad type on operand stack

Any idea if JRebel, the new GenBCode backend or java8-compat is to blame here?

Sounds like SI-9387, which is fixed in 2.11.8. Perhaps you could retest with 2.11.8-SNAPSHOT to check?

-jason 

[Andreas Joseph Krogh]

The only 2.11.8-SNAPSHOT I see on sonatype is org.typelevel. Is org.scala-lang SNAPSHOTs available?

[Jason Zaugg]

You might need to refer to the Sonatype OSS snapshots repo:

Here are the 2.11.8-SNAPSHOT artifacts for the compiler.

-jason

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas Joseph Krogh]

På torsdag 13. august 2015 kl. 13:03:59, skrev Jason Zaugg <jza...@gmail.com>:

You might need to refer to the Sonatype OSS snapshots repo:

 

Here are the 2.11.8-SNAPSHOT artifacts for the compiler.

 

Great!

[Andreas Joseph Krogh]

På torsdag 13. august 2015 kl. 13:05:51, skrev Andreas Joseph Krogh <and...@visena.com>:

På torsdag 13. august 2015 kl. 13:03:59, skrev Jason Zaugg <jza...@gmail.com>:

You might need to refer to the Sonatype OSS snapshots repo:

 

Here are the 2.11.8-SNAPSHOT artifacts for the compiler.

 

Great!

 

I've recompiled with 2.11.8-SNAPSHOT now and still get

 

java.lang.VerifyError: Bad type on operand stack

Exception Details:
 Location:
   scala/compat/java8/JFunction0$mcF$sp.apply()Ljava/lang/Object; @1: invokevirtual
 Reason:
   Type 'scala/compat/java8/JFunction0$mcF$sp' (current frame, stack[0]) is not assignable to 'com/zeroturnaround/reload/F'
 Current Frame:
   bci: @1
   flags: { }
   locals: { 'scala/compat/java8/JFunction0$mcF$sp' }
   stack: { 'scala/compat/java8/JFunction0$mcF$sp' }
 Bytecode:
   0x0000000: 2ab6 001e 9a00 1d2a b800 2459 2aa5 0013
   0x0000010: 59c1 0003 9900 0cc0 0003 b900 2601 00b0
   0x0000020: 572a b900 0101 00b8 0002 b0             
 Stackmap Table:
   same_locals_1_stack_item_frame(@32,Object[#4])
   same_frame(@33)

       at sun.misc.Unsafe.defineAnonymousClass(Native Method)
       at java.lang.invoke.InnerClassLambdaMetafactory.spinInnerClass(InnerClassLambdaMetafactory.java:324)
       at java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite(InnerClassLambdaMetafactory.java:194)
       at java.lang.invoke.LambdaMetafactory.altMetafactory(LambdaMetafactory.java:474)
       at java.lang.invoke.CallSite.makeSite(CallSite.java:325)
       at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
       at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
       at no.officenet.origo.frontend.lift.snippet.calendar.CalendarSnippetHelper$.getSummaryForCalendarEntries(CalendarSnippetHelper.scala:97)
 

 

 

But I'm not getting it when not running with JRebel, so it seems JRebel is messing things up...

[Andreas Joseph Krogh]

På torsdag 13. august 2015 kl. 13:03:59, skrev Jason Zaugg <jza...@gmail.com>:

You might need to refer to the Sonatype OSS snapshots repo:

 

Here are the 2.11.8-SNAPSHOT artifacts for the compiler.

 

Is it possible that this error is caused by the same issue?

 

java.lang.VerifyError: Bad return type
Exception Details:
  Location:
    no/officenet/origo/frontend/lift/comet/BlogSummaryCometActor.createLink(Lno/officenet/origo/frontend/dto/BlogEntrySummaryCometDto;Ljava/lang/String;)Lscala/xml/NodeSeq; @306: areturn
  Reason:
    Type 'scala/collection/AbstractSeq' (current frame, stack[0]) is not assignable to 'scala/xml/NodeSeq' (from method signature)
  Current Frame:
    bci: @306
    flags: { }
    locals: { 'no/officenet/origo/frontend/lift/comet/BlogSummaryCometActor', 'no/officenet/origo/frontend/dto/BlogEntrySummaryCometDto', 'java/lang/String', 'scala/collection/AbstractSeq', 'no/officenet/origo/core/domain/model/AbstractEntityObject' }
    stack: { 'scala/collection/AbstractSeq' }
  Bytecode:
    0x0000000: 2ab6 065e 3a04 1904 c101 3a9a 0006 a700
    0x0000010: 8ab2 0663 b206 68bb 066a 592b b606 70b6
    0x0000020: 0675 b606 7ac0 067c b606 7d2b b606 80b7
    0x0000030: 0683 b606 86b6 067a c006 88b6 068b ba06
    0x0000040: 9400 00c0 05ec b206 992b 3a05 1905 c600
    0x0000050: 06a7 0009 b206 10a7 0011 b206 9e19 05b6
    0x0000060: 0680 b806 a4b6 06a6 b206 ab2c b201 15b6

 

or is SI-9387 addressing issues caused by JFunction* only?

[Andreas Joseph Krogh]

The reason I ask is because I'm getting lots of these, but it's not consistent. A restart of the application helps.

We're using AspectJ (to do Spring DI on Scala classes/objects) and do load-time weaving. Might that cause issues?

 

We've never seen this before switching to -Ybackend:GenBCode

[Jason Zaugg]

Does it only show up with JRebel, or can you reproduce without that?

Could you switch to build-time AspectJ? That would make it easier to inspect the errant classfile (before and after weaving).

-jason

[Andreas Joseph Krogh]

Forgot to say; The original Error (Type 'scala/compat/java8/JFunction0$mcF$sp' (current frame, stack[0]) is not assignable to 'com/zeroturnaround/reload/F') went away when not using JRebel, which we only use for development.

 

The error above (current frame, stack[0]) is not assignable to 'scala/xml/NodeSeq' (from method signature), we're getting in production, but not consistently, and a restart helps. That is; When the code in question is loaded/executed the first time, when the Error occurs it occurs the first time and continues to occur until restart.

 

We're not able to use build-time AspectJ with Scala-sources as AspectJ's compiler doesn't like that, AFAIU.

[Jason Zaugg]

Perhaps try with the Java command line option discussed here: http://stackoverflow.com/questions/15253173/how-safe-is-it-to-use-xx-usesplitverifier

I came to that via https://www.google.com.au/search?q=aspectj+invokedynamic+verifyerror

-jason

--

[Andreas Joseph Krogh]

På onsdag 19. august 2015 kl. 07:41:03, skrev Jason Zaugg <jza...@gmail.com>:

Perhaps try with the Java command line option discussed here: http://stackoverflow.com/questions/15253173/how-safe-is-it-to-use-xx-usesplitverifier

 

I came to that via https://www.google.com.au/search?q=aspectj+invokedynamic+verifyerror

 

Thanks, I'll try that.