summaryrefslogtreecommitdiff
path: root/doc/ref/scheme-debugging.texi
blob: 6168ac886d9ef93eafcb7c741b865891ca85401d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
@c -*-texinfo-*-
@c This is part of the GNU Guile Reference Manual.
@c Copyright (C)  1996, 1997, 2000, 2001, 2002, 2003, 2004
@c   Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.

@page
@node Debugging Features
@section Debugging Features

Guile includes debugging tools to help you work out what is going wrong
when a program signals an error or behaves differently to how you would
expect.  This chapter describes how to use these tools.

Broadly speaking, Guile's debugging support allows you to do two things:

@itemize @bullet
@item
specify @dfn{breakpoints} --- points in the execution of a program where
execution should pause so you can see what is going on

@item
examine in detail the ``scene of the crime'' --- in other words, the
execution context at a breakpoint, or when the last error occurred.
@end itemize

@noindent
The details are more complex and more powerful @dots{}

@menu
* Debug Last Error::            Debugging the most recent error.
* Intro to Breakpoints::        Setting and manipulating them.
* Interactive Debugger::        Using the interactive debugger.
* Tracing::                     Tracing program execution.
@end menu


@node Debug Last Error
@subsection Debugging the Most Recent Error

When an error is signalled, Guile remembers the execution context where
the error occurred.  By default, Guile then displays only the most
immediate information about where and why the error occurred, for
example:

@lisp
(make-string (* 4 (+ 3 #\s)) #\space)
@print{}
standard input:2:19: In procedure + in expression (+ 3 #\s):
standard input:2:19: Wrong type argument: #\s
ABORT: (wrong-type-arg)

Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
@end lisp

@noindent
However, as the message above says, you can obtain much more
information about the context of the error by typing
@code{(backtrace)} or @code{(debug)}.

@code{(backtrace)} displays the Scheme call stack at the point where the
error occurred:

@lisp
(backtrace)
@print{}
Backtrace:
In standard input:
   2: 0* [make-string ...
   2: 1*  [* 4 ...
   2: 2*   [+ 3 #\s]

Type "(debug-enable 'backtrace)" if you would like a backtrace
automatically if an error occurs in the future.
@end lisp

@noindent
In a more complex scenario than this one, this can be extremely useful
for understanding where and why the error occurred.  For more on the
format of the displayed backtrace, see the subsection below.

@code{(debug)} takes you into Guile's interactive debugger, which
provides commands that allow you to

@itemize @bullet
@item
display the Scheme call stack at the point where the error occurred
(the @code{backtrace} command --- see @ref{Display Backtrace})

@item
move up and down the call stack, to see in detail the expression being
evaluated, or the procedure being applied, in each @dfn{frame} (the
@code{up}, @code{down}, @code{frame}, @code{position}, @code{info args}
and @code{info frame} commands --- see @ref{Frame Selection} and
@ref{Frame Information})

@item
examine the values of variables and expressions in the context of each
frame (the @code{evaluate} command --- see @ref{Frame Evaluation}).
@end itemize

Use of the interactive debugger, including these commands, is described
in @ref{Interactive Debugger}.

@menu
* Backtrace Format::            How to interpret a backtrace.
@end menu


@node Backtrace Format
@subsubsection How to Interpret a Backtrace


@node Intro to Breakpoints
@subsection Intro to Breakpoints

If you are not already familiar with the concept of breakpoints, the
first subsection below explains how they work are why they are useful.

Broadly speaking, Guile's breakpoint support consists of

@itemize @bullet
@item
type-specific features for @emph{creating} breakpoints of various types

@item
relatively generic features for @emph{manipulating} the behaviour of
breakpoints once they've been created.
@end itemize

Different breakpoint types are implemented as different classes in a
GOOPS hierarchy with common base class @code{<breakpoint>}.  The magic
of generic functions then allows most of the manipulation functions to
be generic by default but specializable (by breakpoint class) if the
need arises.

Generic breakpoint support is provided by the @code{(ice-9 debugger
breakpoints)} module, so you will almost always need to use this module
in order to access the functionality described here:

@smalllisp
(use-modules (ice-9 debugger breakpoints))
@end smalllisp

@noindent
You may like to add this to your @file{.guile} file.

@menu
* Breakpoints Overview::
* Source Breakpoints::
* Procedural Breakpoints::
* Setting Breakpoints::
* break! trace! trace-subtree!::
* Accessing Breakpoints::
* Breakpoint Behaviours::
* Enabling and Disabling::
* Deleting Breakpoints::
* Breakpoint Information::
* Other Breakpoint Types::
@end menu


@node Breakpoints Overview
@subsubsection How Breakpoints Work and Why They Are Useful

Often, debugging the last error is not enough to tell you what went
wrong.  For example, the root cause of the error may have arisen a long
time before the error was signalled, in which case the execution context
of the error is too late to be useful.  Or your program might not signal
an error at all, just return an unexpected result or have some incorrect
side effect.

In many such cases, it's useful to pause the program at or before the
point where you suspect the problem arises.  Then you can explore the
stack, display the values of key variables, and generally check that the
state of the program is as you expect.  If all is well, you can let the
program continue running normally, or step more slowly through each
expression that the Scheme interpreter evaluates.  Single-stepping may
reveal that the program is going through blocks of code that you didn't
intend --- a useful data point for understanding what the underlying
problem is.

Telling Guile where or when to pause a program is called @dfn{setting a
breakpoint}.  When a breakpoint is hit, Guile's default behaviour is to
enter the interactive debugger, where there are now two sets of commands
available:

@itemize @bullet
@item
all the commands as described for last error debugging (@pxref{Debug
Last Error}), which allow you to explore the stack and so on

@item
additional commands for continuing program execution in various ways:
@code{next}, @code{step}, @code{finish}, @code{trace-finish} and
@code{continue}.
@end itemize

Use of the interactive debugger is described in @ref{Interactive
Debugger}.


@node Source Breakpoints
@subsubsection Source Breakpoints

A source breakpoint is a breakpoint that triggers whenever program
execution hits a particular source location.  A source breakpoint can be
conveniently set simply by evaluating code that has @code{##} inserted
into it at the position where you want the breakpoint to be.

For example, to set a breakpoint immediately before evaluation of
@code{(= n 0)} in the following procedure definition, evaluate:

@smalllisp
(define (fact1 n)
  (if ##(= n 0)
      1
      (* n (fact1 (- n 1)))))
@print{}
Set breakpoint 1: standard input:4:9: (= n 0)
@end smalllisp

@noindent
Note the message confirming that you have set a breakpoint.  If you
don't see this, something isn't working.

@code{##} is provided by the @code{(ice-9 debugger breakpoints source)} module,
so you must use this module before trying to set breakpoints in this
way:

@smalllisp
(use-modules (ice-9 debugger breakpoints source))
@end smalllisp

@noindent
You may like to add this to your @file{.guile} file.

The default behaviour for source breakpoints is @code{debug-here}
(@pxref{Breakpoint Behaviours}), which means to enter the command line
debugger when the breakpoint is hit.  So, if you now use @code{fact1},
that is what happens.

@smalllisp
guile> (fact1 3)
Hit breakpoint 1: standard input:4:9: (= n 0)
Frame 3 at standard input:4:9
        (= n 0)
debug> 
@end smalllisp


@node Procedural Breakpoints
@subsubsection Procedural Breakpoints

A procedural breakpoint is a breakpoint that triggers whenever Guile is
about to apply a specified procedure to its (already evaluated)
arguments.  To set a procedural breakpoint, call @code{break!} with the
target procedure as a single argument.  For example:

@smalllisp
(define (fact1 n)
  (if (= n 0)
      1
      (* n (fact1 (- n 1)))))

(break! fact1)
@print{}
Set breakpoint 1: [fact1]
@result{}
#<<procedure-breakpoint> 808b0b0>
@end smalllisp

Alternatives to @code{break!} are @code{trace!} and
@code{trace-subtree!}.  The difference is that these three calls create
a breakpoint in the same place but with three different behaviours,
respectively @code{debug-here}, @code{trace-here} and
@code{trace-subtree}.  Breakpoint behaviours are documented fully later
(@pxref{Breakpoint Behaviours}), but to give a quick taste, here's an
example of running code that includes a procedural breakpoint with the
@code{trace-here} behaviour.

@smalllisp
(trace! fact1)
@print{}
Set breakpoint 1: [fact1]
@result{}
#<<procedure-breakpoint> 808b0b0>

(fact1 4)
@print{}
|  [fact1 4]
|  |  [fact1 3]
|  |  |  [fact1 2]
|  |  |  |  [fact1 1]
|  |  |  |  |  [fact1 0]
|  |  |  |  |  1
|  |  |  |  2
|  |  |  6
|  |  24
|  24
@result{}
24
@end smalllisp

To set and use procedural breakpoints, you will need to use the
@code{(ice-9 debugger breakpoints procedural)} module:

@smalllisp
(use-modules (ice-9 debugger breakpoints procedural))
@end smalllisp

@noindent
You may like to add this to your @file{.guile} file.


@node Setting Breakpoints
@subsubsection Setting Breakpoints

In general, that is.  We've already seen how to set source and
procedural breakpoints conveniently in practice.  This section explains
how those conveniences map onto a more general mechanism.

The general mechanism for setting breakpoints is the generic function
@code{set-breakpoint!}.  Different kinds of breakpoints define
subclasses of the class @code{<breakpoint>} and provide their own
methods for @code{set-pbreakpoint!}.

For example, @code{(ice-9 debugger breakpoints procedural)} implements
the @code{<procedure-breakpoint>} subclass and provides a
@code{set-breakpoint!} method that takes a procedure argument:

@smalllisp
(set-breakpoint! @var{behavior} fact1)
@print{}
Set breakpoint 1: [fact1]
@result{}
#<<procedure-breakpoint> 808b0b0>
@end smalllisp

A non-type-specific @code{set-breakpoint!} method is provided by the
generic module @code{(ice-9 debugger breakpoints)}.  It allows you to
change the behaviour of an existing breakpoint that is identified by
its breakpoint number.

@smalllisp
(set-breakpoint! @var{behavior} 1)
@end smalllisp

@node break! trace! trace-subtree!
@subsubsection break! trace! trace-subtree!

We have already talked above about the use of @code{break!},
@code{trace!} and @code{trace-subtree!} for setting procedural
breakpoints.  Now that @code{set-breakpoint!} has been introduced, we
can reveal that @code{break!}, @code{trace!} and @code{trace-subtree!}
are in fact just wrappers for @code{set-breakpoint!} that specify
particular breakpoint behaviours, respectively @code{debug-here},
@code{trace-here} and @code{trace-subtree}.

@smalllisp
(break! . @var{args})
    @equiv{} (set-breakpoint! debug-here . @var{args})
(trace! . @var{args})
    @equiv{} (set-breakpoint! trace-here . @var{args})
(trace-subtree! . @var{args})
    @equiv{} (set-breakpoint! trace-subtree . @var{args})
@end smalllisp

This means that these three procedures can be used to set the
corresponding behaviours for any type of breakpoint for which a
@code{set-breakpoint!} method exists, not just procedural ones.


@node Accessing Breakpoints
@subsubsection Accessing Breakpoints

Information about the state and behaviour of a breakpoint is stored in
an instance of the appropriate breakpoint class.  To access and change
that information, therefore, you need to get hold of the desired
breakpoint instance.

The generic function @code{get-breakpoint} meets this need: For every
@code{set-breakpoint!} method there is a corresponding
@code{get-breakpoint} method.  Note especially the useful
type-independent case:

@smalllisp
(get-breakpoint 1)
@result{}
#<<procedure-breakpoint> 808b0b0>
@end smalllisp


@node Breakpoint Behaviours
@subsubsection Breakpoint Behaviours

A breakpoint's @dfn{behaviour} determines what happens when that
breakpoint is hit.  Several kinds of behaviour are generally useful.

@table @code
@item debug-here
Enter the command line debugger.  This gives the opportunity to explore
the stack, evaluate expressions in any of the pending stack frames,
change breakpoint properties or set new breakpoints, and continue
program execution when you are done.

@item trace-here
Trace the current stack frame.  For expressions being evaluated, this
shows the expression.  For procedure applications, it shows the
procedure name and its arguments @emph{post-evaluation}.  For both
expressions and applications, the indentation of the tracing indicates
whether the traced items are mutually tail recursive.

@item trace-subtree
Trace the current stack frame, and enable tracing for all future
evaluations and applications until the current stack frame is exited.
@code{trace-subtree} is a great preliminary exploration tool when all
you know is that there is a bug ``somewhere in XXX or in something that
XXX calls''.

@item (at-exit @var{thunk})
Don't do anything now, but arrange for @var{thunk} to be executed when
the current stack frame is exited.  For example, the operation that most
debugging tools call ``finish'' is @code{(at-exit debug-here)}.

@item (at-next @var{count} @var{thunk})
@dots{} arrange for @var{thunk} to be executed when beginning the
@var{count}th next evaluation or application with source location in the
current file.

@item (at-entry @var{count} @var{thunk})
@dots{} arrange for @var{thunk} to be executed when beginning the
@var{count}th next evaluation (regardless of source location).

@item (at-apply @var{count} @var{thunk})
@dots{} arrange for @var{thunk} to be executed just before performing
the @var{count}th next application (regardless of source location).

@item (at-step @var{count} @var{thunk})
Synthesis of @code{at-entry} and @code{at-apply}; counts both
evaluations and applications.
@end table

Every breakpoint instance has a slot in which its behaviour is stored.
If you have a breakpoint instance in hand, you can change its behaviour
using the @code{bp-behaviour} accessor.

An @dfn{accessor} supports the setting of a property like this:

@smalllisp
(set! (bp-behaviour @var{breakpoint}) @var{new-behaviour})
@end smalllisp

@noindent
See the GOOPS manual for further information on accessors.

Alternatively, if you know how to specify the @var{location-args} for
the breakpoint in question, you can change its behaviour using
@code{set-breakpoint!}.  For example:

@smalllisp
;; Change behaviour of breakpoint number 2.
(set-breakpoint! @var{new-behaviour} 2)

;; Change behaviour of procedural breakpoint on [fact1].
(set-breakpoint! @var{new-behaviour} fact1)
@end smalllisp

In all cases, the behaviour that you specify should be either a single
thunk, or a list of thunks, to be called when the breakpoint is hit.

The most common behaviours above are exported as thunks from the
@code{(ice-9 debugger behaviour)} module.  So, if you use this module, you can
use those behaviours directly like this:

@smalllisp
(use-modules (ice-9 debugger behaviour))
(set-breakpoint! trace-subtree 2)
(set! (bp-behaviour (get-breakpoint 3)) debug-here)
@end smalllisp

@noindent
You can also use the list option to combine common behaviours:

@smalllisp
(set-breakpoint! (list trace-here debug-here) 2)
@end smalllisp

@noindent
Or, for more customized behaviour, you could build and use your own
thunk like this:

@smalllisp
(define (my-behaviour)
  (trace-here)
  (at-exit (lambda ()
             (display "Exiting frame of my-behaviour bp\n")
             ... do something unusual ...)))

(set-breakpoint my-behaviour 2)
@end smalllisp


@node Enabling and Disabling
@subsubsection Enabling and Disabling

Independently of its behaviour, each breakpoint also keeps track of
whether it is currently enabled.  This is a straightforward convenience
to allow breakpoints to be temporarily switched off without losing all
their carefully constructed properties.

If you have a breakpoint instance in hand, you can enable or disable it
using the @code{bp-enabled?} accessor.

Alternatively, you can enable or disable a breakpoint via its location
args by using @code{enable-breakpoint!} or @code{disable-breakpoint!}.

@smalllisp
(disable-breakpoint! fact1)     ; disable the procedural breakpoint on fact1
(enable-breakpoint! 1)          ; enable breakpoint 1
@end smalllisp

@code{enable-breakpoint!} and @code{disable-breakpoint!} are implemented
using @code{get-breakpoint} and @code{bp-enabled?}, so any
@var{location-args} that are valid for @code{get-breakpoint} will work
also for these procedures.


@node Deleting Breakpoints
@subsubsection Deleting Breakpoints

Given a breakpoint instance in hand, you can deactivate it and remove
it from the global list of current breakpoints by calling
@code{bp-delete!}.

Alternatively, you can delete a breakpoint by its location args:

@smalllisp
(delete-breakpoint! 1)         ; delete breakpoint 1
@end smalllisp

@code{delete-breakpoint!} is implemented using @code{get-breakpoint} and
@code{bp-delete!}, so any @var{location-args} that are valid for
@code{get-breakpoint} will work also for @code{delete-breakpoint!}.

There is no way to reinstate a deleted breakpoint.  Final destruction of
the breakpoint instance is determined by the usual garbage collection
rules.


@node Breakpoint Information
@subsubsection Breakpoint Information

To get Guile to print a description of a breakpoint instance, use
@code{bp-describe}:

@smalllisp
(bp-describe (get-breakpoint 1) #t)   ; #t specifies standard output
@print{}
Breakpoint 1: [fact1]
        enabled? = #t
        behaviour = #<procedure trace-here ()>
@end smalllisp

Following the usual model, @code{describe-breakpoint} is also provided:

@smalllisp
(describe-breakpoint 1)
@print{}
Breakpoint 1: [fact1]
        enabled? = #t
        behaviour = #<procedure trace-here ()>
@end smalllisp

Finally, two stragglers.  @code{all-breakpoints} returns a list of all
current breakpoints.  @code{describe-all-breakpoints} combines
@code{bp-describe} and @code{all-breakpoints} by printing a description
of all current breakpoints to standard output.

@node Other Breakpoint Types
@subsubsection Other Breakpoint Types

Besides source and procedural breakpoints, Guile includes an early
implementation of a third class of breakpoints: @dfn{range} breakpoints.
These are breakpoints that trigger when program execution enters (or
perhaps exits) a defined range of source locations.

Sadly, these don't yet work well.  The apparent problem is that the
extra methods for @code{set-breakpoint!} and @code{get-breakpoint} cause
some kind of explosion in the time taken by GOOPS to construct its
method cache and to dispatch calls involving these generic functions.
But we haven't really investigated enough to be sure that this is the
real issue.

If you're interested in looking and/or investigating anyway, please feel
free to check out and play with the @code{(ice-9 debugger breakpoints
range)} module.

The other kind of breakpoint that we'd like to have is watchpoints, but
this hasn't been implemented at all yet.  Watchpoints may turn out to be
impractical for performance reasons.


@node Interactive Debugger
@subsection Using the Interactive Debugger

Guile's interactive debugger is a command line application that accepts
commands from you for examining the stack and, if at a breakpoint, for
continuing program execution in various ways.  Unlike in the normal
Guile REPL, commands are typed mostly without parentheses.

When you first enter the debugger, it introduces itself with a message
like this:

@lisp
This is the Guile debugger -- for help, type `help'.
There are 3 frames on the stack.

Frame 2 at standard input:36:19
        [+ 3 #\s]
debug> 
@end lisp

@noindent
``debug>'' is the debugger's prompt, and a useful reminder that you are
not in the normal Guile REPL.  The available commands are described in
detail in the following subsections.

@menu
* Display Backtrace::           backtrace.
* Frame Selection::             up, down, frame.
* Frame Information::           info args, info frame, position.
* Frame Evaluation::            evaluate.
* Single Stepping::             step, next.
* Run To Frame Exit::           finish, trace-finish.
* Continue Execution::          continue.
* Leave Debugger::              quit.
@end menu


@node Display Backtrace
@subsubsection Display Backtrace

The @code{backtrace} command, which can also be invoked as @code{bt} or
@code{where}, displays the call stack (aka backtrace) at the point where
the debugger was entered:

@lisp
debug> bt
In standard input:
  36: 0* [make-string ...
  36: 1*  [* 4 ...
  36: 2*   [+ 3 #\s]
@end lisp

@deffn {Debugger Command} backtrace [count]
@deffnx {Debugger Command} bt [count]
@deffnx {Debugger Command} where [count]
Print backtrace of all stack frames, or of the innermost @var{count}
frames.  With a negative argument, print the outermost -@var{count}
frames.  If the number of frames isn't explicitly given, the debug
option @code{depth} determines the maximum number of frames printed.
@end deffn

The format of the displayed backtrace is the same as for the
@code{backtrace} procedure --- see @ref{Backtrace Format} for details.


@node Frame Selection
@subsubsection Frame Selection

A call stack consists of a sequence of stack @dfn{frames}, with each
frame describing one level of the nested evaluations and applications
that the program was executing when it hit a breakpoint or an error.
Frames are numbered such that frame 0 is the outermost --- i.e. the
operation on the call stack that began least recently --- and frame N-1
the innermost (where N is the total number of frames on the stack).

When you enter the debugger, the innermost frame is selected, which
means that the commands for getting information about the ``current''
frame, or for evaluating expressions in the context of the current
frame, will do so by default with respect to the innermost frame.  To
select a different frame, so that these operations will apply to it
instead, use the @code{up}, @code{down} and @code{frame} commands like
this:

@lisp
debug> up
Frame 1 at standard input:36:14
        [* 4 ...
debug> frame 0
Frame 0 at standard input:36:1
        [make-string ...
debug> down
Frame 1 at standard input:36:14
        [* 4 ...
@end lisp

@deffn {Debugger Command} up [n]
Move @var{n} frames up the stack.  For positive @var{n}, this
advances toward the outermost frame, to higher frame numbers, to
frames that have existed longer.  @var{n} defaults to one.
@end deffn

@deffn {Debugger Command} down [n]
Move @var{n} frames down the stack.  For positive @var{n}, this
advances toward the innermost frame, to lower frame numbers, to frames
that were created more recently.  @var{n} defaults to one.
@end deffn

@deffn {Debugger Command} frame [n]
Select and print a stack frame.  With no argument, print the selected
stack frame.  (See also ``info frame''.)  An argument specifies the
frame to select; it must be a stack-frame number.
@end deffn


@node Frame Information
@subsubsection Frame Information

[to be completed]

@deffn {Debugger Command} {info frame}
All about selected stack frame.
@end deffn

@deffn {Debugger Command} {info args}
Argument variables of current stack frame.
@end deffn

@deffn {Debugger Command} position
Display the position of the current expression.
@end deffn


@node Frame Evaluation
@subsubsection Frame Evaluation

[to be completed]

@deffn {Debugger Command} evaluate expression
Evaluate an expression.
The expression must appear on the same line as the command,
however it may be continued over multiple lines.
@end deffn


@node Single Stepping
@subsubsection Single Stepping

[to be completed]

@deffn {Debugger Command} step [n]
Continue until entry to @var{n}th next frame.
@end deffn

@deffn {Debugger Command} next [n]
Continue until entry to @var{n}th next frame in same file.
@end deffn


@node Run To Frame Exit
@subsubsection Run To Frame Exit

[to be completed]

@deffn {Debugger Command} finish
Continue until evaluation of the current frame is complete, and
print the result obtained.
@end deffn

@deffn {Debugger Command} trace-finish
Trace until evaluation of the current frame is complete.
@end deffn


@node Continue Execution
@subsubsection Continue Execution

[to be completed]

@deffn {Debugger Command} continue
Continue program execution.
@end deffn


@node Leave Debugger
@subsubsection Leave Debugger

[to be completed]

@deffn {Debugger Command} quit
Exit the debugger.
@end deffn


@node Tracing
@subsection Tracing

Tracing has already been described as a breakpoint behaviour
(@pxref{Breakpoint Behaviours}), but we mention it again here because it
is so useful, and because Guile actually now has @emph{two} mechanisms
for tracing, and its worth clarifying the differences between them.

@menu
* Old Tracing::                 Tracing provided by (ice-9 debug).
* New Tracing::                 Breakpoint-based tracing.
* Tracing Compared::            Differences between old and new.
@end menu


@node Old Tracing
@subsubsection Tracing Provided by @code{(ice-9 debug)}

The @code{(ice-9 debug)} module implements tracing of procedure
applications.  When a procedure is @dfn{traced}, it means that every
call to that procedure is reported to the user during a program run.
The idea is that you can mark a collection of procedures for tracing,
and Guile will subsequently print out a line of the form

@smalllisp
|  |  [@var{procedure} @var{args} @dots{}]
@end smalllisp

whenever a marked procedure is about to be applied to its arguments.
This can help a programmer determine whether a function is being called
at the wrong time or with the wrong set of arguments.

In addition, the indentation of the output is useful for demonstrating
how the traced applications are or are not tail recursive with respect
to each other.  Thus, a trace of a non-tail recursive factorial
implementation looks like this:

@smalllisp
[fact1 4]
|  [fact1 3]
|  |  [fact1 2]
|  |  |  [fact1 1]
|  |  |  |  [fact1 0]
|  |  |  |  1
|  |  |  1
|  |  2
|  6
24
@end smalllisp

While a typical tail recursive implementation would look more like this:

@smalllisp
[fact2 4]
[facti 1 4]
[facti 4 3]
[facti 12 2]
[facti 24 1]
[facti 24 0]
24
@end smalllisp

@deffn {Scheme Procedure} trace procedure
Enable tracing for @code{procedure}.  While a program is being run,
Guile will print a brief report at each call to a traced procedure,
advising the user which procedure was called and the arguments that were
passed to it.
@end deffn

@deffn {Scheme Procedure} untrace procedure
Disable tracing for @code{procedure}.
@end deffn

Here is another example:

@lisp
(define (rev ls)
  (if (null? ls)
      '()
      (append (rev (cdr ls))
              (cons (car ls) '())))) @result{} rev

(trace rev) @result{} (rev)

(rev '(a b c d e))
@result{} [rev (a b c d e)]
   |  [rev (b c d e)]
   |  |  [rev (c d e)]
   |  |  |  [rev (d e)]
   |  |  |  |  [rev (e)]
   |  |  |  |  |  [rev ()]
   |  |  |  |  |  ()
   |  |  |  |  (e)
   |  |  |  (e d)
   |  |  (e d c)
   |  (e d c b)
   (e d c b a)
   (e d c b a)
@end lisp

Note the way Guile indents the output, illustrating the depth of
execution at each procedure call.  This can be used to demonstrate, for
example, that Guile implements self-tail-recursion properly:
 
@lisp
(define (rev ls sl)
  (if (null? ls)
      sl
      (rev (cdr ls)
           (cons (car ls) sl)))) @result{} rev
 
(trace rev) @result{} (rev)
 
(rev '(a b c d e) '())
@result{} [rev (a b c d e) ()]
   [rev (b c d e) (a)]
   [rev (c d e) (b a)]
   [rev (d e) (c b a)]
   [rev (e) (d c b a)]
   [rev () (e d c b a)]
   (e d c b a)
   (e d c b a)
@end lisp
 
Since the tail call is effectively optimized to a @code{goto} statement,
there is no need for Guile to create a new stack frame for each
iteration.  Tracing reveals this optimization in operation.


@node New Tracing
@subsubsection Breakpoint-based Tracing

Guile's newer mechanism implements tracing as an optional behaviour for
any kind of breakpoint.

To trace a procedure (in the same kind of way as the older tracing), use
the @code{trace!} procedure to set a procedure breakpoint with
@code{trace-here} behaviour:

@lisp
(trace! fact1)
@print{}
Set breakpoint 1: [fact1]
@result{}
#<<procedure-breakpoint> 40337bf0>

(fact1 4)
@print{}
|  [fact1 4]
|  |  [fact1 3]
|  |  |  [fact1 2]
|  |  |  |  [fact1 1]
|  |  |  |  |  [fact1 0]
|  |  |  |  |  1
|  |  |  |  2
|  |  |  6
|  |  24
|  24
@result{}
24
@end lisp

To trace evaluation of a source expression, evaluate code containing a
breakpoint marker @code{##} in the appropriate place, then use
@code{set-breakpoint} to change the behaviour of the new breakpoint to
@code{trace-here}:

@lisp
(define (fact1 n)
  (if ##(= n 0)
      1
      (* n (fact1 (- n 1)))))
@print{}
Set breakpoint 4: standard input:13:9: (= n 0)

(use-modules (ice-9 debugger behaviour))
(set-breakpoint! trace-here 4)
@print{}
Breakpoint 4: standard input:13:9: (= n 0)
        enabled? = #t
        behaviour = #<procedure trace-here ()>

(fact1 4)
@print{}
|  (= n 0)
|  #f
|  (= n 0)
|  #f
|  (= n 0)
|  #f
|  (= n 0)
|  #f
|  (= n 0)
|  #t
@result{}
24
@end lisp

@noindent
(Note --- this example reveals a bug: each occurrence of @code{(= n 0)}
should be shown indented with respect to the one before it, as
@code{fact1} does not call itself tail-recursively.)

You can also give a breakpoint the @code{trace-subtree} behaviour, which
means to trace the breakpoint location itself plus any evaluations and
applications that occur below it in the call stack.  In the following
example, this allows us to see the evaluated arguments that are being
compared by the @code{=} procedure:

@lisp
(set-breakpoint! trace-subtree 4)
@print{}
Breakpoint 4: standard input:13:9: (= n 0)
        enabled? = #t
        behaviour = #<procedure trace-subtree ()>

(fact1 4)
@print{}
|  (= n 0)
|  [= 4 0]
|  #f
|  (= n 0)
|  [= 3 0]
|  #f
|  (= n 0)
|  [= 2 0]
|  #f
|  (= n 0)
|  [= 1 0]
|  #f
|  (= n 0)
|  [= 0 0]
|  #t
@result{}
24
@end lisp


@node Tracing Compared
@subsubsection Differences Between Old and New Tracing Mechanisms

The newer tracing mechanism is more general and so more powerful than
the older one: it works for expressions as well as procedure
applications, and it implements the useful @code{trace-subtree}
behaviour as well as the more traditional @code{trace-here}.

The older mechanism will probably become obsolete eventually, but it's
worth keeping it around for a while until we are sure that the new
mechanism is correct and does what programmers need.