Re: Exception in thread "main" java.lang.InternalError: bad type SP:0 st.l:1

[Per Bothner <per@bothner.com>]

On 2/24/22 13:49, Panicz Maciej Godek via Kawa wrote:
> Hi,
> I'm working on my code, and after some recent modificationsI get the
> following error when I try to import my module:
> 
> Exception in thread "main" java.lang.InternalError: bad type SP:0 st.l:1
> code:primitive.sequenceExtent(gnu.lists.Pair,Screen)Extent
>          at gnu.bytecode.Label.setTypes(Label.java:106)
>          at gnu.bytecode.Label.define(Label.java:231)
>          at gnu.expr.LambdaExp.compileEnd(LambdaExp.java:640)
>          at gnu.expr.LambdaExp.compileAsInlined(LambdaExp.java:1522)
>          at gnu.expr.ApplyExp.compile(ApplyExp.java:378)
>          ...
>          at gnu.expr.ModuleExp.evalModule1(ModuleExp.java:246)
>          at kawa.Shell.run(Shell.java:293)
>          at kawa.Shell.run(Shell.java:183)
>          at kawa.repl.processArgs(repl.java:724)
>          at kawa.repl.main(repl.java:830)
> 
> How do I even approach debugging this?

I haven't seen one of those in a while.  This can be tricky, and requires
some understanding of the JVM.  It is almost by definition a bug in Kawa,
not your code.

This is basically a failed consistency check during bytecode generation.
Consider an if-expression:

    (if test-expression then-expression else-expression)

This is compiled to something like:

L0:
   evaluate test-expression
   [for simplicity assume the result is a boolean on the JVM stack]
   if pop-value() is false goto L2
L1:
   evaluate then-expression
   goto L3
L2:
   evaluate else-expression
L3:

The JVM verifier requires that the state of the JVM stack *and* the local variables
after the then-expression and after the else-expression be consistent.
The most simple inconsistency (and the one causing the exception) is that the
length of the stack be the same.  There are other rules, but they're more complicated.
For example if then-branch can set local variable 4 to int and the else-branch
could set it to a float.  That is OK - as long as no code following L3 tries to
use the value of variable 4.  If the then-branch sets stack position 2 to a
java.lang.Integer and the else-branch sets it to a java.lang.Float, that is
OK - as long as code following L3 treats it as the common supertype java.lang.Number.

The JVM bytecode verifier originally had to infer these types by analysing how
the various bytescodes change the type-state.  Java 6 added a "StackMapTable" attribute
which adds information about the type-state in the .class file.
This makes byte-code verification much faster, since the verifier
only to to check that the bytecode is consistent with the StackMapTable.

In your case, one execution path leaves the stack with length 1,
and another leaves the stack with length 0.  You need to figure out
which is correct and why the other one is wrong.  The flag
--debug-print-final-expr is useful for getting the how the source
code looks after various transformations and before code-generation.
You need to understand how that tree maps into bytecode, which is
difficult. The more you can simplify your code the better.

You'll learn a lot about Kawa and the JVM if you can figure this out.
If not, I might be able to take a look - if you can simplify as
much as you can first.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/