File: test.html

package info (click to toggle)
db5.3 5.3.28-12%2Bdeb9u1
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 163,332 kB
  • ctags: 82,990
  • sloc: ansic: 448,411; java: 111,824; tcl: 80,544; sh: 44,326; cs: 33,697; cpp: 21,604; perl: 14,557; xml: 10,799; makefile: 4,106; yacc: 1,003; awk: 965; sql: 801; erlang: 342; python: 216; php: 24; asm: 14
file content (103 lines) | stat: -rw-r--r-- 3,984 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
<!--Copyright (c) 1999, 2013 Oracle and/or its affiliates.  All rights reserved.-->
<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.08 [en] (X11; I; FreeBSD 2.2.8-19990120-SNAP i386) [Netscape]">
</HEAD>
<BODY>

<H2>
<A NAME="Debugging"></A>Debugging and Testing</H2>
We have imported the debugging system from the old test suite into the
new interface to aid in debugging problems.&nbsp; There are several variables
that are available both in gdb as globals to the C code, and variables
in Tcl that the user can set.&nbsp; These variables are linked together
so that changes in one venue are reflected in the other.&nbsp; The names
of the variables have been modified a bit to reduce the likelihood
<BR>of namespace trampling.&nbsp; We have added a double underscore to
all the names.
<P>The variables are all initialized to zero (0) thus resulting in debugging
being turned off.&nbsp; The purpose of the debugging, fundamentally, is
to allow the user to set a breakpoint prior to making a DB call.&nbsp;
This breakpoint is set in the <I>__db_loadme() </I>function.&nbsp; The
user may selectively turn on various debugging areas each controlled by
a separate variable (note they all have two (2) underscores prepended to
the name):
<UL>
<LI>
<B>__debug_on</B> - Turns on the debugging system.&nbsp; This must be on
for any debugging to occur</LI>

<LI>
<B>__debug_print - </B>Turns on printing a debug count statement on each
call</LI>

<LI>
<B>__debug_test -</B> Hits the breakpoint in <I>__db_loadme</I> on the
specific iteration</LI>

<LI>
<B>__debug_stop </B>- Hits the breakpoint in <I>__db_loadme</I> on every
(or the next) iteration</LI>
</UL>
<B>Note to developers:</B>&nbsp; Anyone extending this interface must place
a call to <B>_debug_check()</B> (no arguments) before every call into the
DB library.
<P>There is also a command available that will force a call to the _debug_check
function.
<P><B>> berkdb debug_check</B>
<P>
<HR WIDTH="100%">
<BR>For testing purposes we have added several hooks into the DB library
and a small interface into the environment and/or database commands to
manipulate the hooks.&nbsp; This command interface and the hooks and everything
that goes with it is only enabled when the test option is configured into
DB.
<P><B>> &lt;env> test copy <I>location</I></B>
<BR><B>> &lt;db> test copy <I>location</I></B>
<BR><B>> &lt;env> test abort <I>location</I></B>
<BR><B>> &lt;db> test abort <I>location</I></B>
<P>In order to test recovery we need to be able to abort the creation or
deletion process at various points.&nbsp; Also we want to invoke a copy
function to copy the database file(s)&nbsp; at various points as well so
that we can obtain before/after snapshots of the databases.&nbsp; The interface
provides the test command to specify a <B><I>location</I></B> where we
wish to invoke a <B>copy</B> or an <B>abort</B>.&nbsp; The command is available
from either the environment or the database for convenience.&nbsp; The
<B><I>location</I></B>
can be one of the following:
<UL>
<LI>
<B>none -</B> Clears the location</LI>

<LI>
<B>preopen -</B> Sets the location prior to the __os_open call in the creation
process</LI>

<LI>
<B>postopen</B> - Sets the location to immediately following the __os_open
call in creation</LI>

<LI>
<B>postlogmeta</B> - Sets the location to immediately following the __db_log_page
call to log the meta data in creation.&nbsp; Only valid for Btree.</LI>

<LI>
<B>postlog</B> - Sets the location to immediately following the last (or
only) __db_log_page call in creation.</LI>

<LI>
<B>postsync</B> - Sets the location to immediately following the sync of
the log page in creation.</LI>

<LI>
<B>prerename</B> - Sets the location prior to the __os_rename call in the
deletion process.</LI>

<LI>
<B>postrename</B> - Sets the location to immediately following the __os_rename
call in deletion</LI>
</UL>

</BODY>
</HTML>