From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [IPv6:2a0c:5a00:149::25]) by sourceware.org (Postfix) with ESMTPS id 474123858414 for ; Fri, 25 Feb 2022 01:32:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 474123858414 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bothner.com Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1nNPSm-00Fm9Y-30; Fri, 25 Feb 2022 02:32:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bothner.com ; s=selector1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID; bh=uReyxWZssmIWixxyD6LV2BmBx9Hk92iqiginx/783z4=; b=UUamjqxe/b3czpqursX7F21CHt LhHrZQ5yRRLJEmpfVDUGSjRCxv36bR1Ycv4+K/QhLaU6537RQJ+6Yta0NLkpzihPaTbprFzN5Kr0C Hq3izKFrbHHVA/F8jQJd+CI7ObbLWeBxvJ1DXuPr2ENrbnCFvU1XDqrJti/C20+2qHcQOdqUs6yfA McmQDl8jf5RKPRGYgdFL1XDiN3M+ArVT6JTIiiLrGy93zoEj1nlWQsWDbcXFAszDlNQT0oaRR9AQG 8mSist3CYx/cpU94oBFG66KNxjpffQ5aTDZqi2cwY+Gu8idLtkI4OHTNHFYJqfXqbUJC0LF7vt8ex txYuRlXg==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1nNPSg-0002GT-6V; Fri, 25 Feb 2022 02:31:58 +0100 Received: by submission03.runbox with esmtpsa [Authenticated ID (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1nNPSU-0007Ti-Lv; Fri, 25 Feb 2022 02:31:46 +0100 Message-ID: Date: Thu, 24 Feb 2022 17:31:39 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Exception in thread "main" java.lang.InternalError: bad type SP:0 st.l:1 Content-Language: en-US To: Panicz Maciej Godek , kawa@sourceware.org References: From: Per Bothner In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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 01:32:09 -0000 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/