From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by sourceware.org (Postfix) with ESMTPS id 2BA463858D28 for ; Fri, 25 Feb 2022 16:27:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2BA463858D28 Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-2d07ae0b1c4so38993897b3.11 for ; Fri, 25 Feb 2022 08:27:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UX3MmLxejoRUg71IP30sBzJZW+icuCiwv0epkzqxNYg=; b=VWNom9S5qG2LKGa0eSm8UZ9xgJ7RlRSmcZbXD/USt1C45662z/g59vsbHktpjL41ID 6itRavz7yHW3XBl6DAPhjdHBkuw6oG6MHiaXKRqGGogkHt1Xmqqz/rNPaPmtHptHpMx0 a2Lm1Yi5LTZI6e6j7lSSa8+RT56K9EP7gT3uMrxnbXatB38Ub6JRIThnjF/tpwushRzH yg4dGlMmS4feOl2xl4LfvyjD0dsTVvEFlBPpyQBBfLLO9alQvREixQoVfbiHyg7oRJfD 5M9fvWY8pVdRkoDjp7bL3gkmgnaQsKnoDaZJysAaFZF1tFhju2zx0A+P7a+7KTewUfkC cR2A== X-Gm-Message-State: AOAM532bwAmtySquOjR1T4YfVxiID9iC77snwvefk/+ErF6cMJb5wCKq YDhh8gaUK+qO/15eBDlKkge9NVfb2FqyhP/uNMzh8krCwu4= X-Google-Smtp-Source: ABdhPJxrhm61ktaLqxYwaTyojC4ULymoskfSI7FAg2f30ArLgSrVJmLqpgiHQw1MoNWH8s6ozUCPYFupCUN0IEkdnH0= X-Received: by 2002:a81:4743:0:b0:2d1:5f32:7e95 with SMTP id u64-20020a814743000000b002d15f327e95mr8371805ywa.138.1645806420357; Fri, 25 Feb 2022 08:27:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Panicz Maciej Godek Date: Fri, 25 Feb 2022 17:26:46 +0100 Message-ID: Subject: Re: Exception in thread "main" java.lang.InternalError: bad type SP:0 st.l:1 To: Per Bothner Cc: kawa@sourceware.org X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 16:27:03 -0000 pt., 25 lut 2022 o 02:32 Per Bothner napisa=C5=82(a): > > > 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. > > Actually, there were a number of bugs in my hastily refactored code. I don't exactly know the root cause. I suppose that the reason for this was that due to uncautious refactoring, I have passed "object" class instead of an actual value (which was meant to be a cons pair in that context). But I also had some erroneous type annotations. If you're curious, this commit fixed the bug for me: https://github.com/panicz/grasp-android/commit/0cc6226bd9773728610b7501fbf0= eda1e3110d65 (to reproduce the bug, it should be sufficient to import the (primitive) module) > > 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 analysin= g > 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. > > Thanks for the detailed explanation. I expect that one day, I will learn how JVM and Kawa operate under the hood, but that day is yet to come. I was a bit surprised that I got that weird stack trace, but actually the top of the stack did contain the sufficient hint (i.e. the name of the function that caused the trouble). Anyway, thanks for taking the trouble of explaining all that to me! Best regards, Panicz