Home:	Bugloo 0.3.0 reference manual
Previous chapter:	Starting the debugger
Next chapter:	Execution control

Break requests commands

3.1	Break requests based on control flow
	3.1.1	Breakpoint requests
	3.1.2	Activating and deleting breakpoints
3.2	Break requests based on data access
	3.2.1	Watchpoint requests
	3.2.2	Activating and deleting watchpoints
3.3	Break requests based on incorrect execution
	3.3.1	Exception requests
	3.3.2	Activating and deleting exception requests

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

3.1.1 Breakpoint requests

There are three basic primitives that can be used to control the execution of the debuggee based on its control flow.

The first one is breakpoint. A breakpoint can be set at any line that contains executable statements in the source code. The debuggee is suspended each time the program reaches a breakpoint.

The second one is footprint. A footprint is very similar to a breakpoint, except that it does not suspend the debuggee. It is a convenient way of locating where the program went in the source code.

The last one is conditional breakpoint. It's a breakpoint that suspends the execution of the program only when its condition is true. In Bugloo, the condition language is Scheme : a condition is a lambda expression or a closure that decides whether the program has to be suspended or not.

Set a breakpoint in JVM class <classname>, at line <line>

Set a breakpoint in JVM class <classname>, in method <methodname>

Set a footprint in JVM class <classname>, at line <line>

Set a footprint in JVM class <classname>, in method <methodname>

Set a conditional breakpoint in JVM class <classname>, at line <line>

Set a conditional breakpoint in JVM class <classname>, in method <methodname>

Display all breakpoint and footprint requests

Setting breakpoints or footprints by using commands with <methodname> can abort. This is due to the fact that many methods with the same name can be defined inside a JVM class. To raise ambiguity, the complete JNI method name must be given.

When you set a conditional breakpoint, you must give a string representing the lambda that will act as the condition. This lambda take one argument that is the lexical environment of the debuggee at the place where it was stopped. If the lambda returns #f then the breakpoint will not suspend debuggee execution, otherwise it will.

You can access the value of the variables bound in the lexical environment by the mean of the (env-ref <environment> <variable>) form.

Given the following Bigloo module:

1:(module reverse) 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:(reverse '(1 2 3 4 5))

If you want to suspend debuggee execution at line 5 when list l contains less than 3 elements, you might write somthing like:

(cbp add "(lambda (env) (< (length (env-ref env 'l)) 3))" reverse 5)

At last, you can give breakpoints and footprints a lifetime, by setting the optional parameter <life>. Given the last bigloo module, you can set a footprint that will expire after 4 iterations by writing :

(fp add reverse 5 4)

By default, omitting <life> argument is the same as setting its value to -1.

breakpoint 2 set in string:21

Later, you can enable, disable or delete this request by using this identifier.

Take into account the <n>th break request at next resume

Do not take into account the <n>th break request at next resume

Delete the <n>th break request

Delete all break requests that are still alive

3.2.1 Watchpoint requests

Access Watchpoint is the break request that suspends the debuggee when a field of a JVM class is going to be readed.

Modification Watchpoint is the break request that suspends the debuggee when a field of a JVM class is going to be written.

Set an access watchpoint on field <fieldname> in JVM class <classname>

Set a modification watchpoint on field <fieldname> in JVM class <classname>

Like breakpoints, watchpoints can have a lifetime that is at creation time by the mean of the optional parameter <life>.

Take into account the <n>th watchpoint at next resume

Do not take into account the <n>th watchpoint at next resume

Delete the <n>th watchpoint

Delete all watchpoints that are still alive

3.3.1 Exception requests

Bugloo allows you to suspend the debuggee for any kind of JVM exception that can be thrown during the execution, by the mean of exception requests.

Set an exception request for JVM class <classname>

Display all exception requests

Display informations about the last thrown exception

There are basically two different kinds of situation where an exception can be thrown. Either it will be caught by some try-catch block present in the call stack, or the debuggee program will end with an uncaught exception error.

The kind of exceptions Bugloo will watch for depends on the value of the <kind> argument. The two preceding kinds of exception can be watched by using respectively the symbol 'caugh or 'uncaugh. You can also monitor both kinds at a time by using the symbol 'both.

Note that Bugloo relies on JVMDI to make the difference between caught exceptions and uncaughts ones at runtime, and that sometimes this distinction cannot be made properly. This is especially true when there are native functions in the call stack of the thread that raised the exception. See JVMDI documentation for more informations on this limitation.

Take into account the <n>th exception request at next resume

Do not take into account the <n>th exception request at next resume

Delete the <n>th exception request

Delete all exception requests that are still alive