1<!--Copyright 1999,2008 Oracle. All rights reserved.--> 2<HTML> 3<HEAD> 4 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> 5 <META NAME="GENERATOR" CONTENT="Mozilla/4.08 [en] (X11; I; FreeBSD 2.2.8-19990120-SNAP i386) [Netscape]"> 6</HEAD> 7<BODY> 8 9<H2> 10<A NAME="Debugging"></A>Debugging and Testing</H2> 11We have imported the debugging system from the old test suite into the 12new interface to aid in debugging problems. There are several variables 13that are available both in gdb as globals to the C code, and variables 14in Tcl that the user can set. These variables are linked together 15so that changes in one venue are reflected in the other. The names 16of the variables have been modified a bit to reduce the likelihood 17<BR>of namespace trampling. We have added a double underscore to 18all the names. 19<P>The variables are all initialized to zero (0) thus resulting in debugging 20being turned off. The purpose of the debugging, fundamentally, is 21to allow the user to set a breakpoint prior to making a DB call. 22This breakpoint is set in the <I>__db_loadme() </I>function. The 23user may selectively turn on various debugging areas each controlled by 24a separate variable (note they all have two (2) underscores prepended to 25the name): 26<UL> 27<LI> 28<B>__debug_on</B> - Turns on the debugging system. This must be on 29for any debugging to occur</LI> 30 31<LI> 32<B>__debug_print - </B>Turns on printing a debug count statement on each 33call</LI> 34 35<LI> 36<B>__debug_test -</B> Hits the breakpoint in <I>__db_loadme</I> on the 37specific iteration</LI> 38 39<LI> 40<B>__debug_stop </B>- Hits the breakpoint in <I>__db_loadme</I> on every 41(or the next) iteration</LI> 42</UL> 43<B>Note to developers:</B> Anyone extending this interface must place 44a call to <B>_debug_check()</B> (no arguments) before every call into the 45DB library. 46<P>There is also a command available that will force a call to the _debug_check 47function. 48<P><B>> berkdb debug_check</B> 49<P> 50<HR WIDTH="100%"> 51<BR>For testing purposes we have added several hooks into the DB library 52and a small interface into the environment and/or database commands to 53manipulate the hooks. This command interface and the hooks and everything 54that goes with it is only enabled when the test option is configured into 55DB. 56<P><B>> <env> test copy <I>location</I></B> 57<BR><B>> <db> test copy <I>location</I></B> 58<BR><B>> <env> test abort <I>location</I></B> 59<BR><B>> <db> test abort <I>location</I></B> 60<P>In order to test recovery we need to be able to abort the creation or 61deletion process at various points. Also we want to invoke a copy 62function to copy the database file(s) at various points as well so 63that we can obtain before/after snapshots of the databases. The interface 64provides the test command to specify a <B><I>location</I></B> where we 65wish to invoke a <B>copy</B> or an <B>abort</B>. The command is available 66from either the environment or the database for convenience. The 67<B><I>location</I></B> 68can be one of the following: 69<UL> 70<LI> 71<B>none -</B> Clears the location</LI> 72 73<LI> 74<B>preopen -</B> Sets the location prior to the __os_open call in the creation 75process</LI> 76 77<LI> 78<B>postopen</B> - Sets the location to immediately following the __os_open 79call in creation</LI> 80 81<LI> 82<B>postlogmeta</B> - Sets the location to immediately following the __db_log_page 83call to log the meta data in creation. Only valid for Btree.</LI> 84 85<LI> 86<B>postlog</B> - Sets the location to immediately following the last (or 87only) __db_log_page call in creation.</LI> 88 89<LI> 90<B>postsync</B> - Sets the location to immediately following the sync of 91the log page in creation.</LI> 92 93<LI> 94<B>prerename</B> - Sets the location prior to the __os_rename call in the 95deletion process.</LI> 96 97<LI> 98<B>postrename</B> - Sets the location to immediately following the __os_rename 99call in deletion</LI> 100</UL> 101 102</BODY> 103</HTML> 104