|
4.1 Suspending and resuming execution
|
| (resume . <nbtimes>) | Bugloo command |
Start/Resume the execution of the debuggee program
| argument | description |
|---|
| <nbtimes>::int | how many resumes to do at once |
When Bugloo is started, the debuggee is in
suspended mode. To start execution, you must call the resume
command at least once. The execution will continue until next break
request or until program ends. It is possible to do multiple resumes
at once by specifying optional argument <nbtimes>.
Sometimes you might want to suspend the execution of
the debuggee without having to wait for a breakpoint to be reached
(e.g. in case of an event-driven program like GUIs). With Bugloo,
you can achieve this by sending an Interrupt Signal to the
debuggee. On Unix platform, this is usually done by typing CTRL+C inside the console.
When the debuggee is suspended, you can resume the program by
executing small portions of code. It's called stepping.
| (step . <nbtimes>) | Bugloo command |
| (step <depth> . <nbtimes>) | Bugloo command |
| (step <depth> <size> . <nbtimes>) | Bugloo command |
Resume the execution of the debuggee program
| argument | description |
|---|
| <depth>::symbol | step policy. Either 'into, 'over or 'out |
| <size>::symbol | step size. Either 'line or 'min |
| <nbtimes>::int | how many steps to do at once |
Let the following scheme program :
1:(define (foo)
2: (print (bar '(1 2 3)))
3: (print (bar '(a b c))))
4:
5:(define (bar l)
6: (cons 'gee l))
7:
8:(foo) |
Suppose the execution is suspended at line 2. There are
three different ways of stepping :
- into: step to line 6 to execute bar function
- over: execute whole line 2 (bar is executed and its
result is printed). step to line 3
- out: execute the rest of function foo. terminate the
program
By default, value of <depth> is set to 'into.
Argument <size> is normally not needed. It is
used when stepping into a line. If <size> is set to 'min,
the unit of execution is the JVM bytecode, otherwise the unit of
execution is the line.
Like the resume command, you can specify how many step
to do at once by setting the optional argument <nbtimes>.
When stepping into programs, it is often necessary to automatically
skip steps in some parts of the execution. You certainly don't want to
step into JVM proprietary classes during initialization, neither you
want to follow step by step the construction of every Scheme's pair of
your program.
You can tell Bugloo which of these special cases you
want to filter.
4.3.1 Class filters
You can specify a list of JVM classes for which you never want to step
into. Class filter is part of the JVMDI API. It is done in the debuggee
VM and thus avoid traffic between the debugger VM and the debuggee VM.
| (filter class add <expression>) | Bugloo command |
| (filter class add ( <expression> ... )) | Bugloo command |
Add a class or a list of classes to the filter list
| (filter class remove <expression>) | Bugloo command |
| (filter class remove ( <expression> ... )) | Bugloo command |
Remove a class or a list of classes from the filter list
| (filter class set <expression>) | Bugloo command |
| (filter class set ( <expression> ... )) | Bugloo command |
Set the filter list to a class or a list of classes
| argument | description |
|---|
| <expression>::string | class not to step into |
<expression> is a restricted regular
expression as defined in the JVMDI Specification. These regular
expressions are limited to exact matches and patterns that begin with
'*' or end with '*'.
A good example is the default classes filter that is set
by Bugloo at startup.
;; A default (quite reasonable) class filter for scheme debugging ...
(filter class add
("java.*"
"javax.*"
"sun.*"
"com.sun.*"
"bigloo.*")) |
4.3.2 Extended filters
Extended filters are more powerful, in that they allow full stepping
control over the traced methods. But they are Bugloo's addition to
JVMDI debugging facilities. They can't stop traffic between the
debugger and the debuggee, and thus are slower than standard class
filters.
| (filter ext add ( <expression> . <action> )) | Bugloo command |
| (filter ext add ( ( <expression> . <action> ) ... )) | Bugloo command |
Add a location-action or a list of location-actions to the
extendend filter list
| (filter ext remove ( <expression> . <action> )) | Bugloo command |
| (filter ext remove ( ( <expression> . <action> ) ... )) | Bugloo command |
Remove a location-action or a list of location-actions from the
extendend filter list
| (filter ext set ( <expression> . <action> )) | Bugloo command |
| (filter ext set ( ( <expression> . <action> ) ... )) | Bugloo command |
Set the extended filter list to a location-action or a list
of location-actions
| argument | description |
|---|
| <expression>::string | The location (class + method) to filter |
| <action>::symbol | The type of filter. Either 'out or 'next |
Here, the location is the entire couple class + method. The filter is
a full posix regular expression that can match this type of location.
With it you can for example filter all the classes that contains a
particular method name.
There's two type of action that can be taken when a filter matches a
location. They have a relationship with the call stack of the debuggee
:
-
The 'out action correspond to the behavior of classes filter. The
execution continues until the located method return.
-
The 'next action is slightly more complicated. If no method calls are
present inside the located method ( i.e. the method is a leaf )
then the behavior is to the 'out action. Else the execution continues
until the the first method call is reached.
A good example is the default extended filter that is set
by Bugloo at startup.
;; A default extended filter to mask some Bigloo implementation tricks ...
(filter ext add ("\\.funcall[0-4]\\(" . next))
(filter ext add ("<clinit>" . out))
(filter ext add ("<init>" . out)) |
|