debug and backtrace

debug and backtrace

[Mike Gran]

Hi-

With the default behavior of 1.9.x, REPL debug and backtrace are broken.
Consider the following example run using 'guile --debug' and
(debug-enable 'backtrace).

With 1.8.5

--------------------------------------------------------
guile> (string-append "abc" (string-append "def" (string-append (error
"blammo"))))

Backtrace:
In standard input:
   2: 0* [string-append "abc" ...
   2: 1*  [string-append "def" ...
   2: 2*   [string-append ...
   2: 3*    [error "blammo"]

standard input:2:58: In procedure error in expression (error "blammo"):
standard input:2:58: blammo
ABORT: (misc-error)
guile> (debug)
This is the Guile debugger -- for help, type `help'.
There are 4 frames on the stack.

Frame 3 at standard input:2:58
	[error "blammo"]
debug> up
Frame 2 at standard input:2:43
	[string-append ...
debug> up
Frame 1 at standard input:2:22
	[string-append "def" ...
debug> up
Frame 0 at standard input:2:1
	[string-append "abc" ...
--------------------------------------------------------

With 1.9.x

--------------------------------------------------------
scheme@(guile-user)> (string-append "abc" (string-append
"def" (string-append (error "blammo"))))

Backtrace:
In unknown file:
   ?: 0* [#<vm a0389b8> #<program a272300 at standard input:1:0 ()>]
   ?: 1* [error "blammo"]

ERROR: In procedure error:
ERROR: blammo
scheme@(guile-user)> (debug)
This is the Guile debugger -- for help, type `help'.
There are 2 frames on the stack.

Frame 1 at unknown source location
	[error "blammo"]
debug> up
Frame 0 at unknown source location
	[#<vm a0389b8> #<program a272300 at standard input:1:0 ()>]
--------------------------------------------------------

Thanks,
Mike

Re: debug and backtrace

[Ludovic Courtès]

Hello!

Mike Gran <spk121@yahoo.com> writes:

> With the default behavior of 1.9.x, REPL debug and backtrace are broken.

Indeed, it looks like the VM frames are ignored.

Another example:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (letrec ((f (lambda (x) (g x))) (g (lambda (x) (x)))) (f (lambda () (make-stack #t))))
$1 = #<stack 6bebc0:ce3ce0>
scheme@(guile-user)> (display-backtrace $1 (current-output-port))
In unknown file:
   ?: 0* [#<vm 7002d0> #<program ce3da0 at <unknown port>:0:0 ()>]
   ?: 1* [make-stack #t #t]
scheme@(guile-user)> (stack-length $1)
$2 = 2
--8<---------------cut here---------------end--------------->8---

as opposed to:

--8<---------------cut here---------------start------------->8---
guile> (letrec ((f (lambda (x) (g x))) (g (lambda (x) (x)))) (f (lambda () (make-stack #t))))
$1 = #<stack 7f17ea928420:7f17ea8008a0>
guile> (display-backtrace $1 (current-output-port))
In unknown file:
   ?: 0* [primitive-eval (letrec ((f #) (g #)) (f (lambda () #)))]
   1: 1* (letrec ((f (lambda # #)) (g (lambda # #))) (f (lambda () (make-stack #t))))
   1: 2  [f #<procedure #f ()>]
   ...
   1: 3  [gsubr-apply #<primitive-procedure make-stack> #t]
guile> (stack-length $1)
$2 = 4
--8<---------------cut here---------------end--------------->8---

I’ll try to investigate this.

Ludo’.

Re: debug and backtrace

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Mike Gran <spk121@yahoo.com> writes:
>
>> With the default behavior of 1.9.x, REPL debug and backtrace are broken.
>
> Indeed, it looks like the VM frames are ignored.

I've just hit this too.  So here's another example, just in case it's
useful.

Given a file testcar.scm that contains

((lambda _
   (car 1)))

1.8.x guile --debug -s testcar.scm gives a useful backtrace:

Backtrace:
In unknown file:
   ?: 0* [primitive-load "testcar.scm"]
In testcar.scm:
   2: {1}* [#<procedure #f _>]
   3: 2  [car {1}]

testcar.scm:3:4: In procedure car in expression (car 1):
testcar.scm:3:4: Wrong type (expecting pair): 1

But current (approximately speaking) Git master doesn't:

Backtrace:
In unknown file:
   ?: 0* [dynamic-wind #<program 9817a00 at ice-9/boot-9.scm:1771:18 ()> ...]
   ?: {1}* [with-fluid* #<fluid 9> #f #<program 98179a0 at ice-9/boot-9.scm:935:4 ()>]
   ?: 2* [load-compiled/vm "/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/home/neil/SW/Guile/testcar.scm.go"]

ERROR: In procedure vm-debug-engine:
ERROR: Wrong type argument in position 1 (expecting pair): 1

Out of interest, is this something that has worked with the VM in the
past, and has somehow got broken?  Or is it something that hasn't been
implemented for the VM yet?  (I believe it's the former, but I'm not
sure.)

Regards,
        Neil

Re: debug and backtrace

[Andy Wingo]

Hi Mike,

On Sun 13 Sep 2009 16:30, ludo@gnu.org (Ludovic Courtès) writes:

> Mike Gran <spk121@yahoo.com> writes:
>
>> With the default behavior of 1.9.x, REPL debug and backtrace are broken.
>
> Indeed, it looks like the VM frames are ignored.

Hopefully by the next release, and certainly by the following one, this
will be fixed: by having everything on the VM stack. So yes it sucks
now, but it's because we have so many kinds of procedures and stacks
that it's tough to make a nice debugging interface.

Andy
-- 
http://wingolog.org/

Re: debug and backtrace

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi Mike,
>
> On Sun 13 Sep 2009 16:30, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mike Gran <spk121@yahoo.com> writes:
>>
>>> With the default behavior of 1.9.x, REPL debug and backtrace are broken.
>>
>> Indeed, it looks like the VM frames are ignored.
>
> Hopefully by the next release, and certainly by the following one, this
> will be fixed: by having everything on the VM stack. So yes it sucks
> now, but it's because we have so many kinds of procedures and stacks
> that it's tough to make a nice debugging interface.

Actually I think I just found and fixed one problem.  From the time when
a #<program> was a SMOB, really_make_boot_program in vm.c was still
using SCM_SET_SMOB_FLAGS to set the SCM_F_PROGRAM_IS_BOOT flag - which
meant that it was setting flag 1<<32 :-) which obviously was then missed
by the SCM_PROGRAM_IS_BOOT calls in stacks.c.

So now, with my test script

  ((lambda _
     (car 1) 23))

I get a backtrace:

  neil@arudy:~/SW/Guile/git$ meta/guile --debug -s ../testcar.scm 
  Backtrace:
  In ice-9/boot-9.scm:
  1772: 0* [save-module-excursion #<program 9dc0630 at ice-9/boot-9.scm:1785:3 ()>]
  In unknown file:
     ?: {1}* [dynamic-wind #<program 9dc0620 at ice-9/boot-9.scm:1771:18 ()> ...]
  In ice-9/boot-9.scm:
   935: 2* [load "../testcar.scm"]
  In unknown file:
     ?: 3* [with-fluid* #<fluid 9> #f #<program 9dc0600 at ice-9/boot-9.scm:935:4 ()>]
  In ice-9/boot-9.scm:
   940: 4* [#<program 9dc0600 at ice-9/boot-9.scm:935:4 ()>]
  In unknown file:
     ?: 5* [load-compiled/vm "/home/neil/SW/Guile/git/cache/guile/ccache/1.9-0.D-LE-4/home/neil/SW/Guile/testcar.scm.go"]
  In ../testcar.scm:
     2: 6* [#<program 9e3e4e0 at ../testcar.scm:0:1 _> 23]

  ERROR: In procedure vm-debug-engine:
  ERROR: Wrong type argument in position 1 (expecting pair): 1

I'll push the fix a bit later.  (I also have fixes for the incorrect
stack count warning.)

But I notice that there is only ever one frame per VM.  E.g. with code
like

  (define (foo n)
    (let ((a 1))
      (let ((b 2))
        (string-append (* a b)))))

(which deliberately passes an invalid arg to string-append), the
interpreter backtrace would show the two `let' frames, whereas the VM
backtrace doesn't.

Is that intended, or something else to investigate?

Regards,
        Neil

Re: debug and backtrace

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Actually I think I just found and fixed one problem.  From the time when
> a #<program> was a SMOB, really_make_boot_program in vm.c was still
> using SCM_SET_SMOB_FLAGS to set the SCM_F_PROGRAM_IS_BOOT flag - which
> meant that it was setting flag 1<<32 :-) which obviously was then missed
> by the SCM_PROGRAM_IS_BOOT calls in stacks.c.

Good catch, excellent!

Ludo’.