Spurious line numbers

Spurious line numbers

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

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)

The problem with the second and the third line is that the stepper module
contains some 700 lines, so that the lines 10145 and 10108 don't even exist.

What is the likely reason for this behavior?

(I can help reproduce it if needed - in the sources of GRASP - but I don't
think I'll find time to build a minimal reproducible example)

Re: Spurious line numbers

[Per Bothner]

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/