Backtraces in Guile 2.0

Backtraces in Guile 2.0

[Mike Gran]

Hi-

I have a few questions about how backtraces are supposed to work.

But let me start at the beginning, I guess.

If I create a file named "symbol1.scm" that contains the
single erroneous line.


  (symbol->string "STRING")

If I run that script, it creates a backtrace for the error but
says it happens in "unknown file".  It seems to me that the file
is easily knowable.  Is that the expected behavior?


The autocompiled backtrace has 


   In module/ice-9/boot-9.scm:
   1917: 3 [save-module-excursion #<procedure 14f3180 at module/ice-9/boot-9.scm:3341:3 ()>]
   3348: 2 [#<procedure 14f3180 at module/ice-9/boot-9.scm:3341:3 ()>]
   In unknown file:
      ?: 1 [load-compiled/vm "/home/mike/.cache/guile/ccache/2.0-LE-8-2.0/home/mike/Documents/code/guile_backtrace/symbol1.scm.go"]
      ?: 0 [symbol->string "STRING"]

   ERROR: In procedure symbol->string:
   ERROR: In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): "STRING"

and the non-auto-compiled backtrace is similar

   In module/ice-9/boot-9.scm:
   1917: 5 [save-module-excursion #<procedure b5b180 at module/ice-9/boot-9.scm:3341:3 ()>]
   3348: 4 [#<procedure b5b180 at module/ice-9/boot-9.scm:3341:3 ()>]
   1189: 3 [%start-stack load-stack ...]
   1194: 2 [#<procedure a762d0 ()>]
   In unknown file:
      ?: 1 [primitive-load "/home/mike/Documents/code/guile_backtrace/symbol1.scm"]
      ?: 0 [symbol->string "STRING"]

   ERROR: In procedure symbol->string:
   ERROR: In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): "STRING"


Thanks,

Mike

Re: Backtraces in Guile 2.0

[Klaus Schilling]

From: Mike Gran <spk121@yahoo.com>
Subject: Backtraces in Guile 2.0
Date: Mon, 21 Feb 2011 19:23:03 -0800 (PST)

> Hi-
> 
> I have a few questions about how backtraces are supposed to work.
> 
> But let me start at the beginning, I guess.
> 
> If I create a file named "symbol1.scm" that contains the
> single erroneous line.
> 
> 
>   (symbol->string "STRING")
> 
> If I run that script, it creates a backtrace for the error but
> says it happens in "unknown file".  It seems to me that the file
> is easily knowable.  Is that the expected behavior?
> 
> 
> The autocompiled backtrace has 
> 
> 
>    In module/ice-9/boot-9.scm:
>    1917: 3 [save-module-excursion #<procedure 14f3180 at module/ice-9/boot-9.scm:3341:3 ()>]
>    3348: 2 [#<procedure 14f3180 at module/ice-9/boot-9.scm:3341:3 ()>]
>    In unknown file:
>       ?: 1 [load-compiled/vm "/home/mike/.cache/guile/ccache/2.0-LE-8-2.0/home/mike/Documents/code/guile_backtrace/symbol1.scm.go"]
>       ?: 0 [symbol->string "STRING"]
> 
>    ERROR: In procedure symbol->string:
>    ERROR: In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): "STRING"
> 
> and the non-auto-compiled backtrace is similar
> 
>    In module/ice-9/boot-9.scm:
>    1917: 5 [save-module-excursion #<procedure b5b180 at module/ice-9/boot-9.scm:3341:3 ()>]
>    3348: 4 [#<procedure b5b180 at module/ice-9/boot-9.scm:3341:3 ()>]
>    1189: 3 [%start-stack load-stack ...]
>    1194: 2 [#<procedure a762d0 ()>]
>    In unknown file:
>       ?: 1 [primitive-load "/home/mike/Documents/code/guile_backtrace/symbol1.scm"]
>       ?: 0 [symbol->string "STRING"]
> 
>    ERROR: In procedure symbol->string:
>    ERROR: In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): "STRING"
> 

When booting and before loading the script indicated by the -s switch,
guile comes to operate in a ``virtual file'' in which the command line is
processed, among other things. It's not really a file, thence unknown, it just behaves, at
least for the debugger's viewpoint, like a file containing the
instruction to load symbol1.scm or compiling load1.scm and thereupon
load the compiled code.

Klaus Schilling

Re: Backtraces in Guile 2.0

[Andy Wingo]

Hi Mike,

On Tue 22 Feb 2011 04:23, Mike Gran <spk121@yahoo.com> writes:

>   (symbol->string "STRING")
>
>    In module/ice-9/boot-9.scm:
>    1917: 3 [save-module-excursion #<procedure 14f3180 at module/ice-9/boot-9.scm:3341:3 ()>]
>    3348: 2 [#<procedure 14f3180 at module/ice-9/boot-9.scm:3341:3 ()>]
>    In unknown file:
>       ?: 1 [load-compiled/vm "/home/mike/.cache/guile/ccache/2.0-LE-8-2.0/home/mike/Documents/code/guile_backtrace/symbol1.scm.go"]
>       ?: 0 [symbol->string "STRING"]

Here, there is no procedure in the call chain that has source
annotations corresponding to symbol1.scm.  Though, it does seem to me
that the load-compiled/vm line is unnecessary; instead we should load up
the .go into a thunk, and run that thunk without recursing through the
load-compiled/vm primitive.

In any case it seems that symbol1.scm.go tail-calls symbol->string, so
we are left without source info.  Bummer.  We could improve this by
keeping a ring buffer of previous frames, like JRM suggests in
http://funcall.blogspot.com/2009/05/you-knew-id-say-something-part-iv.html.

Regards,

Andy
-- 
http://wingolog.org/

Re: Backtraces in Guile 2.0

[Mike Gran]

> From:Andy Wingo <wingo@pobox.com>
> In any case it seems that symbol1.scm.go tail-calls symbol->string, so
> we are left without source info.  Bummer.  We could improve this by
> keeping a ring buffer of previous frames, like JRM suggests in
> http://funcall.blogspot.com/2009/05/you-knew-id-say-something-part-iv.html.

So, the specific line on which the error occurred will always read
"in unknown file" because source data is a property of procedures.  And,
when procedure A tail-calls procedure B, the backtrace may only
display the information of the procedure A.  Right?

Thus, if I understand correctly, the closest I can get to getting source
info for this trivial case would be to change the script to

  (symbol->string "HELLO")
  #t

Adding a #t so it can't be tail-called.  Then I get

In unknown file:
   ?: 2 [load-compiled/vm "/home/Mike/.cache/guile/ccache/2.0-LE-4-2.0/home/Mike/tmp.scm.go"]
In /home/Mike/tmp.scm:
   1: 1 [#<procedure 13fa550 ()>]
In unknown file:
   ?: 0 [symbol->string "STRING"]
ERROR: In procedure symbol->string:

Thanks,

-Mike

Re: Backtraces in Guile 2.0

[Andy Wingo]

On Tue 22 Feb 2011 18:53, Mike Gran <spk121@yahoo.com> writes:

> So, the specific line on which the error occurred will always read
> "in unknown file" because source data is a property of procedures.  And,
> when procedure A tail-calls procedure B, the backtrace may only
> display the information of the procedure A.  Right?

Right.

> Thus, if I understand correctly, the closest I can get to getting source
> info for this trivial case would be to change the script to
>
>   (symbol->string "HELLO")
>   #t

Yep.

> Adding a #t so it can't be tail-called.  Then I get
>
> In unknown file:
>    ?: 2 [load-compiled/vm "/home/Mike/.cache/guile/ccache/2.0-LE-4-2.0/home/Mike/tmp.scm.go"]
> In /home/Mike/tmp.scm:
>    1: 1 [#<procedure 13fa550 ()>]
> In unknown file:
>    ?: 0 [symbol->string "STRING"]
> ERROR: In procedure symbol->string:

Is this what you want?  It seems right to me...

Andy
-- 
http://wingolog.org/

Re: Backtraces in Guile 2.0

[Linas Vepstas]

Hi,

On 22 February 2011 13:13, Andy Wingo <wingo@pobox.com> wrote:
> On Tue 22 Feb 2011 18:53, Mike Gran <spk121@yahoo.com> writes:
>
>> So, the specific line on which the error occurred will always read
>> "in unknown file" because source data is a property of procedures.  And,
>> when procedure A tail-calls procedure B, the backtrace may only
>> display the information of the procedure A.  Right?
>
> Right.
>
>> Thus, if I understand correctly, the closest I can get to getting source
>> info for this trivial case would be to change the script to
>>
>>   (symbol->string "HELLO")
>>   #t
>
> Yep.
>
>> Adding a #t so it can't be tail-called.  Then I get
>>
>> In unknown file:
>>    ?: 2 [load-compiled/vm "/home/Mike/.cache/guile/ccache/2.0-LE-4-2.0/home/Mike/tmp.scm.go"]
>> In /home/Mike/tmp.scm:
>>    1: 1 [#<procedure 13fa550 ()>]
>> In unknown file:
>>    ?: 0 [symbol->string "STRING"]
>> ERROR: In procedure symbol->string:
>
> Is this what you want?  It seems right to me...

Well, I'm not exactly following all of the argument, so the following might
be off the mark, and not an issue, but, superficially at least ...

If there are multiple large files involved, and one of them has a bug,
and there's no printing of the filename, then locating the offending code
could be tedious & tricky .. one can't just try to alter every possible
tail call in one's code to see if its buggy .. !?

--linas

Re: Backtraces in Guile 2.0

[Mike Gran]

> From:Andy Wingo <wingo@pobox.com>
> > Thus, if I understand correctly, the closest I can get to getting source
> > info for this trivial case would be to change the script to
> >
> >   (symbol->string "HELLO")
> >   #t
> 
> Yep.
> 
> > Adding a #t so it can't be tail-called.  Then I get
> >
> > In unknown file:
> >    ?: 2 [load-compiled/vm 
> "/home/Mike/.cache/guile/ccache/2.0-LE-4-2.0/home/Mike/tmp.scm.go"]
> > In /home/Mike/tmp.scm:
> >    1: 1 [#<procedure 13fa550 ()>]
> > In unknown file:
> >    ?: 0 [symbol->string "STRING"]
> > ERROR: In procedure symbol->string:
> 
> Is this what you want?  It seems right to me...

My expectation of debuggers has been formed by my experience with
GDB and MSVC, so I'm still trying to work out for myself where I
think Guile's debugging could use improving and where the analogy
to GDB is faulty.

To say something completely incoherent, I feel like the 
debugger isn't giving me enough information to solve my problems:
I feel like it should be easier to know where I am in the source
and where I am in the stack. But to improve on the above incoherent
statement, I first need to understand what the expected behavior
actually is and how to best take advantage of the functionality
that exists.

Thanks,

-Mike