Home:	Bugloo 0.3.0 reference manual
Previous chapter:	Name Manglers and Displayers
Next chapter:	Debug sessions

Getting informations during execution

6.1	Call stack
	6.1.1	Exploring the call stack of a thread
	6.1.2	Setting the current frame
6.2	Arguments and Local variables
	6.2.1	Variables value
	6.2.2	Variables introspection
6.3	Evaluating Scheme expressions typed at runtime
6.4	Managing threads

Chapters

1.	Quick introduction
2.	Starting the debugger
3.	Break requests commands
4.	Execution control
5.	Name Manglers and Displayers
6.	Getting informations during execution
7.	Debug sessions
8.	Debugging of Memory Allocation
9.	Recording events during the execution
10.	Miscellaneous commands
11.	Manual Index

6.1.1 Exploring the call stack of a thread

Display the call stack of the suspended thread

Return the size of the call stack

Return the line in source code the debuggee stopped at

When the execution of the debuggee is suspended, Bugloo can display informations about the call stack of the program. A call stack is the stack of every function that are still waiting for a result to return. An element of this stack is called a frame.

Let the following example module:

  1:(module str (main go))
  2:
  3:(define (%reverse l)
  4:   (define (iter l acc)
  5:      (if (null? l)
  6:          acc
  7:          (iter (cdr l) (cons (car l) acc))))
  8:   (iter l '()))
  9:
 10:(define (go args)
 11:   (print args)
 12:   (let ((mylist (list 1 2 3 4 5)))
 13:      (print (%reverse mylist))))

If execution was suspended at line 7, invocation of the command (info stack) might return :

(bugloo)  (info stack) 
#0  (%reverse ::obj) in module str:10
#1  (go ::pair) in module str:22
#2  bigloo_main(java.lang.Object) in module str (no line info...)
#3  main(java.lang.String[]) in module str (no line info...)

Frame #0 is the top of the stack : when execution will be resumed, the function %reverse will be the first to return.

Note that name mangling is automatically applied, based on the function type Bugloo infers.

You can query informations on arguments that belong to a specific frame in the call stack. Instead of specifying the frame number each time you ask for argument values, you can tell Bugloo that you're working implicitely with a specific frame number :

Set the current frame number

Return the current frame number

6.2.1 Variables value

Display name and value of all variables of the current frame

Display name and value of variable <varname>

Display name and value of the currently selected object. See chapter Debugging of Memory Allocation.

In the last example, the call of (info args) could have return :

(bugloo)  (info args 0) 
acc (::pair) = (2 1)
l (::pair) = (3 4 5)

Bugloo provides introspection commodities à la Java :

Display each JVM fields of the local variable named <varname>

Display each JVM fields of the currently selected object. See chapter Debugging of Memory Allocation.

These three commands differ in the way they introspect their argument.

The first one simply display each field defined in the JVM class of the argument. It uses the current Displayer in use by the Name Mangler in charge of the argument. It does not display values of a field that is an JVM array. This prevent screen flooding that can occurs when arrays are too large.

The second one is more verbose. It recurse into arrays by displaying their elements.

The last one acts like the second one, but is truly recursive. Whenever it must display a field that is a JVM class, the command recursively introspects into it.

Sometimes, showing the value of a variable is not sufficient to understand a bug. Rather, a more interactive way of debugging is often needed.

Printing the value of some S-expression

Evaluate a Scheme S-expression and print the result.

Evaluate a Scheme S-expression. Print the result and store it in the currently selected object.

By using print! instead of print, it is possible to store the result of the evaluation of the S-expression in %obj%, the currently selected object. For exemple, suppose that the debuggee is suspended at line 7 of the following program:

1:(module str (main go)) 2: 3:(define (%reverse l) 4: (define (iter l acc) 5: (if (null? l) 6: acc 7: (iter (cdr l) (cons (car l) acc)))) 8: (iter l '())) 9: 10:(define (go args) 11: (print args) 12: (let ((mylist (list 1 2 3 4 5))) 13: (print (%reverse mylist))))

Suppose the user has resumed the debugger many times before and that local variables are in the following state:

(bugloo) (info args) acc (::pair) = (2 1) l (::pair) = (3 4 5 6)

The user can evaluate an S-expression, display and store its result by typing:

(bugloo) (print! (cons acc l)) ((2 1) 3 4 5 6)

Later, he can reuse the result of the evaluation by referencing the currently selected object:

(bugloo) (print %obj%) ((2 1) 3 4 5 6)

You can verify that using the print command will not overwrite the value of the currently selected object:

(bugloo) (print (cddr %obj%)) (4 5 6) (bugloo) (print %obj%) ((2 1) 3 4 5 6)

Embedded Scheme interpreter

Start a new interpreter in the debuggee program

Like the print command, local variables that are visible at the location the debuggee is suspended are captured and bound in the environment of the interpreter.

Unlike other languages, there's a native concept of threading in Java, and thus in the JVM. When the debuggee is suspended, Bugloo provides some commands to obtain some informations about the debuggee's threads.

(info threads)

Bugloo command

Display a list of all threads present in the debuggee

Display the current thread

Set the current thread to be <threadnum>

Once the debuggee is suspended, the command (info threads) can be used to show the threads that reside in the debuggee VM. Invocation of this command might return something like:

(bugloo)  (info threads) 
[345] Signal Dispatcher (runnable)
[346] Finalizer (wait)
[347] Reference Handler (wait)
[1] main (runnable)

Each line of output correspond to a thread in the JVM. The number inside the square brackets is the UID of the thread. It is a integer that uniquely identify a thread throughout its whole life. Next, this UID is followed by the name of the thread. At last, the information inside brackets correspond to the state of this thread when the debuggee execution was suspended.

Every preceding commands seen in this chapter (like call stack visualization, variable inspection etc...) work on a per-thread basis. These commands operate on the current thread.

By default, when the debuggee is suspended, the current thread is set to the thread that cause the suspension (e.g. the one who reached a breakpoint). Later you can choose the thread you want to inspect by setting another current thread. The argument <threadnum> is the UID returned after the invocation of the command (info threads).