1
<!--Copyright 1999-2002 by Sleepycat Software, Inc.-->
2
<!--All rights reserved.-->
5
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
6
<META NAME="GENERATOR" CONTENT="Mozilla/4.08 [en] (X11; I; FreeBSD 2.2.8-19990120-SNAP i386) [Netscape]">
11
<A NAME="Debugging"></A>Debugging and Testing</H2>
12
We have imported the debugging system from the old test suite into the
13
new interface to aid in debugging problems. There are several variables
14
that are available both in gdb as globals to the C code, and variables
15
in Tcl that the user can set. These variables are linked together
16
so that changes in one venue are reflected in the other. The names
17
of the variables have been modified a bit to reduce the likelihood
18
<BR>of namespace trampling. We have added a double underscore to
20
<P>The variables are all initialized to zero (0) thus resulting in debugging
21
being turned off. The purpose of the debugging, fundamentally, is
22
to allow the user to set a breakpoint prior to making a DB call.
23
This breakpoint is set in the <I>__db_loadme() </I>function. The
24
user may selectively turn on various debugging areas each controlled by
25
a separate variable (note they all have two (2) underscores prepended to
29
<B>__debug_on</B> - Turns on the debugging system. This must be on
30
for any debugging to occur</LI>
33
<B>__debug_print - </B>Turns on printing a debug count statement on each
37
<B>__debug_test -</B> Hits the breakpoint in <I>__db_loadme</I> on the
38
specific iteration</LI>
41
<B>__debug_stop </B>- Hits the breakpoint in <I>__db_loadme</I> on every
42
(or the next) iteration</LI>
44
<B>Note to developers:</B> Anyone extending this interface must place
45
a call to <B>_debug_check()</B> (no arguments) before every call into the
47
<P>There is also a command available that will force a call to the _debug_check
49
<P><B>> berkdb debug_check</B>
52
<BR>For testing purposes we have added several hooks into the DB library
53
and a small interface into the environment and/or database commands to
54
manipulate the hooks. This command interface and the hooks and everything
55
that goes with it is only enabled when the test option is configured into
57
<P><B>> <env> test copy <I>location</I></B>
58
<BR><B>> <db> test copy <I>location</I></B>
59
<BR><B>> <env> test abort <I>location</I></B>
60
<BR><B>> <db> test abort <I>location</I></B>
61
<P>In order to test recovery we need to be able to abort the creation or
62
deletion process at various points. Also we want to invoke a copy
63
function to copy the database file(s) at various points as well so
64
that we can obtain before/after snapshots of the databases. The interface
65
provides the test command to specify a <B><I>location</I></B> where we
66
wish to invoke a <B>copy</B> or an <B>abort</B>. The command is available
67
from either the environment or the database for convenience. The
68
<B><I>location</I></B>
69
can be one of the following:
72
<B>none -</B> Clears the location</LI>
75
<B>preopen -</B> Sets the location prior to the __os_open call in the creation
79
<B>postopen</B> - Sets the location to immediately following the __os_open
83
<B>postlogmeta</B> - Sets the location to immediately following the __db_log_page
84
call to log the meta data in creation. Only valid for Btree.</LI>
87
<B>postlog</B> - Sets the location to immediately following the last (or
88
only) __db_log_page call in creation.</LI>
91
<B>postsync</B> - Sets the location to immediately following the sync of
92
the log page in creation.</LI>
95
<B>prerename</B> - Sets the location prior to the __os_rename call in the
96
deletion process.</LI>
99
<B>postrename</B> - Sets the location to immediately following the __os_rename
100
call in deletion</LI>
104
<BR><B>> <env> mutex <I>mode nitems</I></B>
105
<P>This command creates a mutex region for testing. It sets the mode
106
of the region to <B><I>mode</I></B> and sets up for <B><I>nitems</I></B>
107
number of mutex entries. After we successfully get a handle to a
108
mutex we create a command of the form <B><I>$env.mutexX</I></B>, where
109
X is an integer starting at 0 (e.g. <B>$env.mutex0, $env.mutex1,
110
</B>etc).
111
We use the <I>Tcl_CreateObjCommand() </I> to create the top level
112
mutex function. It is through this handle that the user can access
113
all of the commands described below. Internally, the mutex handle
114
is sent as the <I>ClientData</I> portion of the new command set so that
115
all future mutex calls access the appropriate handle.
117
<HR WIDTH="100%"><B>> <mutex> close</B>
118
<P>This command closes the mutex and renders the handle invalid.
119
This command directly translates to the __db_r_detach function call.
120
It returns either a 0 (for success), or it throws a Tcl error with
122
<P>Additionally, since the handle is no longer valid, we will call <I>Tcl_DeleteCommand()
124
that further uses of the handle will be dealt with properly by Tcl itself.
125
<HR WIDTH="100%"><B>> <mutex> get <I>id</I></B>
126
<P>This command locks the mutex identified by <B><I>id</I></B>. It
127
returns either a 0 (for success), or it throws a Tcl error with a
130
<HR WIDTH="100%"><B>> <mutex> release <I>id</I></B>
131
<P>This command releases the mutex identified by <B><I>id</I></B>.
132
It returns either a 0 (for success), or it throws a Tcl error with
135
<HR WIDTH="100%"><B>> <mutex> getval <I>id</I></B>
136
<P>This command gets the value stored for the mutex identified by <B><I>id</I></B>.
137
It returns either the value, or it throws a Tcl error with a system
140
<HR WIDTH="100%"><B>> <mutex> setval <I>id val</I></B>
141
<P>This command sets the value stored for the mutex identified by <B><I>id
143
<B><I>val</I></B>.
144
It returns either a 0 (for success), or it throws a Tcl error with