~ubuntu-branches/ubuntu/maverick/evolution-data-server/maverick-proposed

« back to all changes in this revision

Viewing changes to libdb/tcl/docs/test.html

  • Committer: Bazaar Package Importer
  • Author(s): Didier Roche
  • Date: 2010-05-17 17:02:06 UTC
  • mfrom: (1.1.79 upstream) (1.6.12 experimental)
  • Revision ID: james.westby@ubuntu.com-20100517170206-4ufr52vwrhh26yh0
Tags: 2.30.1-1ubuntu1
* Merge from debian experimental. Remaining change:
  (LP: #42199, #229669, #173703, #360344, #508494)
  + debian/control:
    - add Vcs-Bzr tag
    - don't use libgnome
    - Use Breaks instead of Conflicts against evolution 2.25 and earlier.
  + debian/evolution-data-server.install,
    debian/patches/45_libcamel_providers_version.patch:
    - use the upstream versioning, not a Debian-specific one 
  + debian/libedata-book1.2-dev.install, debian/libebackend-1.2-dev.install,
    debian/libcamel1.2-dev.install, debian/libedataserverui1.2-dev.install:
    - install html documentation
  + debian/rules:
    - don't build documentation it's shipped with the tarball

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
<!--Copyright 1999-2002 by Sleepycat Software, Inc.-->
2
 
<!--All rights reserved.-->
3
 
<HTML>
4
 
<HEAD>
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]">
7
 
</HEAD>
8
 
<BODY>
9
 
 
10
 
<H2>
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.&nbsp; 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.&nbsp; These variables are linked together
16
 
so that changes in one venue are reflected in the other.&nbsp; The names
17
 
of the variables have been modified a bit to reduce the likelihood
18
 
<BR>of namespace trampling.&nbsp; We have added a double underscore to
19
 
all the names.
20
 
<P>The variables are all initialized to zero (0) thus resulting in debugging
21
 
being turned off.&nbsp; The purpose of the debugging, fundamentally, is
22
 
to allow the user to set a breakpoint prior to making a DB call.&nbsp;
23
 
This breakpoint is set in the <I>__db_loadme() </I>function.&nbsp; 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
26
 
the name):
27
 
<UL>
28
 
<LI>
29
 
<B>__debug_on</B> - Turns on the debugging system.&nbsp; This must be on
30
 
for any debugging to occur</LI>
31
 
 
32
 
<LI>
33
 
<B>__debug_print - </B>Turns on printing a debug count statement on each
34
 
call</LI>
35
 
 
36
 
<LI>
37
 
<B>__debug_test -</B> Hits the breakpoint in <I>__db_loadme</I> on the
38
 
specific iteration</LI>
39
 
 
40
 
<LI>
41
 
<B>__debug_stop </B>- Hits the breakpoint in <I>__db_loadme</I> on every
42
 
(or the next) iteration</LI>
43
 
</UL>
44
 
<B>Note to developers:</B>&nbsp; Anyone extending this interface must place
45
 
a call to <B>_debug_check()</B> (no arguments) before every call into the
46
 
DB library.
47
 
<P>There is also a command available that will force a call to the _debug_check
48
 
function.
49
 
<P><B>> berkdb debug_check</B>
50
 
<P>
51
 
<HR WIDTH="100%">
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.&nbsp; This command interface and the hooks and everything
55
 
that goes with it is only enabled when the test option is configured into
56
 
DB.
57
 
<P><B>> &lt;env> test copy <I>location</I></B>
58
 
<BR><B>> &lt;db> test copy <I>location</I></B>
59
 
<BR><B>> &lt;env> test abort <I>location</I></B>
60
 
<BR><B>> &lt;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.&nbsp; Also we want to invoke a copy
63
 
function to copy the database file(s)&nbsp; at various points as well so
64
 
that we can obtain before/after snapshots of the databases.&nbsp; 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>.&nbsp; The command is available
67
 
from either the environment or the database for convenience.&nbsp; The
68
 
<B><I>location</I></B>
69
 
can be one of the following:
70
 
<UL>
71
 
<LI>
72
 
<B>none -</B> Clears the location</LI>
73
 
 
74
 
<LI>
75
 
<B>preopen -</B> Sets the location prior to the __os_open call in the creation
76
 
process</LI>
77
 
 
78
 
<LI>
79
 
<B>postopen</B> - Sets the location to immediately following the __os_open
80
 
call in creation</LI>
81
 
 
82
 
<LI>
83
 
<B>postlogmeta</B> - Sets the location to immediately following the __db_log_page
84
 
call to log the meta data in creation.&nbsp; Only valid for Btree.</LI>
85
 
 
86
 
<LI>
87
 
<B>postlog</B> - Sets the location to immediately following the last (or
88
 
only) __db_log_page call in creation.</LI>
89
 
 
90
 
<LI>
91
 
<B>postsync</B> - Sets the location to immediately following the sync of
92
 
the log page in creation.</LI>
93
 
 
94
 
<LI>
95
 
<B>prerename</B> - Sets the location prior to the __os_rename call in the
96
 
deletion process.</LI>
97
 
 
98
 
<LI>
99
 
<B>postrename</B> - Sets the location to immediately following the __os_rename
100
 
call in deletion</LI>
101
 
</UL>
102
 
 
103
 
<HR WIDTH="100%">
104
 
<BR><B>> &lt;env> mutex <I>mode nitems</I></B>
105
 
<P>This command creates a mutex region for testing.&nbsp; 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.&nbsp; 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&nbsp; 0 (e.g. <B>$env.mutex0, $env.mutex1,
110
 
</B>etc).&nbsp;&nbsp;
111
 
We use the <I>Tcl_CreateObjCommand()&nbsp;</I> to create the top level
112
 
mutex function.&nbsp; It is through this handle that the user can access
113
 
all of the commands described below.&nbsp; 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.
116
 
<P>
117
 
<HR WIDTH="100%"><B>> &lt;mutex> close</B>
118
 
<P>This command closes the mutex and renders the handle invalid.&nbsp;&nbsp;
119
 
This command directly translates to the __db_r_detach function call.&nbsp;
120
 
It returns either a 0 (for success),&nbsp; or it throws a Tcl error with
121
 
a system message.
122
 
<P>Additionally, since the handle is no longer valid, we will call <I>Tcl_DeleteCommand()
123
 
</I>so
124
 
that further uses of the handle will be dealt with properly by Tcl itself.&nbsp;
125
 
<HR WIDTH="100%"><B>> &lt;mutex> get <I>id</I></B>
126
 
<P>This command locks the mutex identified by <B><I>id</I></B>.&nbsp; It
127
 
returns either a 0 (for success),&nbsp; or it throws a Tcl error with a
128
 
system message.
129
 
<BR>
130
 
<HR WIDTH="100%"><B>> &lt;mutex> release <I>id</I></B>
131
 
<P>This command releases the mutex identified by <B><I>id</I></B>.&nbsp;
132
 
It returns either a 0 (for success),&nbsp; or it throws a Tcl error with
133
 
a system message.
134
 
<BR>
135
 
<HR WIDTH="100%"><B>> &lt;mutex> getval <I>id</I></B>
136
 
<P>This command gets the value stored for the mutex identified by <B><I>id</I></B>.&nbsp;
137
 
It returns either the value,&nbsp; or it throws a Tcl error with a system
138
 
message.
139
 
<BR>
140
 
<HR WIDTH="100%"><B>> &lt;mutex> setval <I>id val</I></B>
141
 
<P>This command sets the value stored for the mutex identified by <B><I>id
142
 
</I></B>to
143
 
<B><I>val</I></B>.&nbsp;
144
 
It returns either a 0 (for success),&nbsp; or it throws a Tcl error with
145
 
a system message.
146
 
<BR>
147
 
<HR WIDTH="100%">
148
 
<BR>&nbsp;
149
 
</BODY>
150
 
</HTML>