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 151313858D39 for ; Tue, 19 Sep 2023 00:09:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 151313858D39 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 mailtransmit03.runbox ([10.9.9.163] 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 1qiOIs-00CYKj-Pb; Tue, 19 Sep 2023 02:09:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bothner.com ; s=selector2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID; bh=RhitOFIxlXkpVKgqxXPXN3km5CYB5/B/wC6cMAsB+z0=; b=mAo5eqlGn5JhZox9n5AK8MJQ12 4l/188+NvUjyCrNy/BhE/jiwdkZssb7ae6LRw2SkF7xr0TiEFrH67xWfBZJON5Z8pMFhL2N9Y5+h4 ULIBl2JeeeYiVJlIYc8w87MVWy0Oq9x85612qMduqSs/5+BaYXkoN0llSQhkI9IZz9iqxvLl87DCO HE5ZNdkclv7g/BwF+XrJceD73f0MG7HJL+Vqych9pE+zs3GtHNwO4/lqiNpYeiWzasKvPfhJRNo5N XhzB17nTBLZozbJedO+FaYVkmwm9OUTKdF0LGiw8lhNAlh0kaljJ7PemgxEBQMjM7QFoAP4eIP4ty 4Ry87mEw==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1qiOIs-0007gR-3M; Tue, 19 Sep 2023 02:09:22 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1qiOIZ-0005IQ-7F; Tue, 19 Sep 2023 02:09:03 +0200 Message-ID: <6366ab02-2a8f-ac67-dce8-6b7515c9a81b@bothner.com> Date: Mon, 18 Sep 2023 17:08:55 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Spurious line numbers Content-Language: en-US To: Panicz Maciej Godek , kawa 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=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/18/23 14:25, Panicz Maciej Godek via Kawa wrote: > I have a question. > Recently, I've been developing a module called "stepper", and as I > occasionally get some stack traces, they look more or less like this: > > at gnu.mapping.Procedure.apply2(Procedure.java:160) > at stepper$frame7.lambda33reduce(stepper.scm:10145) > at stepper$frame7.lambda33reduce(stepper.scm:10108) > at stepper.reduce$check(stepper.scm:541) I believe this is generated in this file: gnu/bytecode/SourceDebugExtAttr.java. This was meant to handle the SourceDebugExtension from JSR-45, and (reading from the commment) it's meant to provide a "fall-back" mode. I *think* this may happen if you use (include ...) or possibly if expanding a macro defined in a different file. Probably if you subtract 10000 you might get a reasonable result. I don't know how many current debuggers make use of SourceDebugExtension. The hope is you would get a better stack trace if you use a SourceDebugExtension-aware debugger, but perhaps we should stop generating it. -- --Per Bothner per@bothner.com http://per.bothner.com/