Re: debugging help: how to read/use a backtrace?

[Andy Wingo <wingo@pobox.com>]

On Tue 07 Mar 2017 16:42, Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Andy Wingo writes:
>
>> On Sat 21 Jan 2017 11:21, Jan Nieuwenhuizen <janneke@gnu.org> writes:
>>
>>> I often find myself struggling to pinpoint an error location from
>>> Guile's backtrace (see below) and I am starting to wonder if there is
>>> something that I'm missing.
>>
>> I believe this is comprehensively cleaned up and improved in 2.1.x.
>> (Guile 2.0 tries to identify the procedure by looking at slot 0; Guile
>> 2.2 instead uses the instruction pointer of the frame.)  Can you
>> confirm?
>
> Sadly no; this is 2.1.x (x=5 probably) as you can see from this bit
>
>      l/l=#<procedure 13000a0 at ice-9/eval.scm:342:13 (a b c d)>

What is this l/l syntax?

The way the procedure prints indicates that you have an interpreted
procedure instead of a compiled procedure.  Debugging will be not as
good.  Of course performance also will not be as good.  Still, in theory
these procedures are decorated with properties to indicate their name,
etc, at least when you print the procedure itself:

   scheme@(guile-user)> ,o interp #t
   scheme@(guile-user)> (define foo (lambda (x y z) (list x y z)))
   scheme@(guile-user)> foo
   $1 = #<procedure foo (a b c)>

In a backtrace it could be that the procedure slot was re-used and so
you just have the IP of the procedure's code (at ice-9/eval.scm:342:13)
but that code corresponds to many closures, and the closure itself is
gone.

In summary, debugging interpreted procedures can improve but I suspect
it will never be as good as compiled procedures.

Andy