]> git.sur5r.net Git - bacula/bacula/blob - regress/README
Add explicit debug example
[bacula/bacula] / regress / README
1              Bacula Regression
2                Kern Sibbald
3
4 This is Bacula's regression script directory.
5
6 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
7 Warning!!!! Make sure not to run it on the same system 
8 with your production Catalog because the tables will all
9 be cleared. You can run it on the your production system
10 if you use a different database. E.g. if your production
11 system uses MySQL, you can use SQLite here.
12 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
13
14
15 To set it up, create your personal configuration file, by
16 copying prototype.conf to xxx.conf or simply editing prototype.conf
17 directly.
18
19 Then edit your conf file and define appropriate values
20 for the variables that are in that file.  If you want to see
21 a real example, look at kern.conf, but please don't use my
22 email address!
23
24 If you are using SQLite, make sure that depkgs is pre-built if it
25 isn't already: (cd your-depkgs; make sqlite).
26
27 Note, if you use any database other than SQLite, be sure it is not              
28 your production database because Bacula will delete all the tables
29 and recreate them.  With SQLite, a new different database is created,
30 so it will not affect your production system.
31
32 Using the .conf file, you can now select between any Catalog type:
33 SQLite, SQLite3, MySQL, or PostgreSQL.  Be aware, however, if you
34 use an installed database on a production server, running these
35 tests will delete all the tables !!!!!!!!!!!!!!!!!!  I run my
36 tests on a non-production machine, and in addition, I normally use
37 SQLite as the database, while my production uses MySQL.
38
39 Then do:
40
41    ./config xxx.conf
42    make setup
43
44 You run the above one time.  This will build a Makefile from
45 Makefile.in and your xxx.conf file, copy the Bacula source,
46 configure, build it, and configure all the Bacula scripts
47 and conf files.  If you change your source, you will need to
48 redo this command.
49
50 Then you can run any of the tests in the tests subdirectory.
51 Each test whose name ends in -root requires you to be root for
52 a resonable run.  Each test is totally independent of any other
53 test. Aside from the required "make setup", each test is totally
54 self-initalizing and should clean up after itself.
55
56 All the tests expect you to execute them from the main regress 
57 directory!               
58
59 You can run all the disk based tests by doing:
60
61   ./do_file
62
63 The disk based tests are totally separate from any production
64 system, provided you have configured the database appropriately     
65 as noted above.
66
67 You can run all the disk and most of the tape tests by doing:
68
69   ./do_all
70
71 ======== Important !!! ============
72 When running the tape tests, Bacula will write on any tape that
73 is in the tape drive that you have configured.  If it is a production
74 Bacula tape, it will be destroyed.  If you have configured an Autochanger,
75 Bacula will write on the tapes in slots 1 and 2 thus destroying any
76 information on those tapes, even if they are Bacula production tapes.
77 =================================== 
78
79 Each of the above calls one or more scripts. By looking at the
80 scripts available in this directory, you can see that there are a number
81 of options for running tests.
82
83 You can run them individually as:
84
85    tests/two-jobs-test
86
87 or all non-root tests (my normal testing under my account)
88
89   ./all-non-root-tests
90
91 or all tests (I only run these before a production release):
92
93    su
94    ./all-tests
95
96
97 after running the root tests, while still root, it is a good idea
98 to do:
99
100    make reset
101
102 this cleans up any files that may be created with root permissions.
103
104 If you want to add more tests, do so by putting the shell script 
105 in the tests subdirectory. Be careful when adding (or better not)
106 new clients, pools, and such to the test-bacula-dir.conf.in file
107 as it may invalidate a good number of tests, which respond to
108 questions by answering with a number (i.e. the order of the selection
109 list is known). It might be better to add your own testb-bacula...
110 configuration file.  
111
112 To avoid re-doing a make setup if you have made a change to the
113 conf files, and you do not need a new copy of the source, you can simply do:
114
115    make sed
116
117 Debugging failed tests:
118 Prior versions required editing the tests/xxxx and changing a debug flag.
119 However, that has been replaced by two environment variables:
120
121    REGRESS_DEBUG
122    REGRESS_WAIT
123
124 If you define REGRESS_DEBUG, e.g.
125
126    REGRESS_DEBUG=1
127    export REGRESS_DEBUG
128
129 then run a test, it will display the job and debug output.
130
131 If you define REGRESS_WAIT, the script will stop and request:
132
133 Start Bacula under debugger and enter anything when ready ...
134
135 At this point, you can start any of the daemons under the debugger,
136 then answer the message by entering any character.  The script will         
137 then continue. For any daemon or daemons that you have manually started,
138 you will see an error message when the script attempts to run a second
139 copy, but those messages can be ignored.  This makes it reasonably easy
140 to run any component or components under the debugger if necessary.
141
142 Explicit example:
143
144 In shell window 1.
145
146 cd regress
147 export REGRESS_DEBUG=1
148 export REGRESS_WAIT=1
149 tests/name-of-script-test
150 (wait until it tells you to start the debugger)
151
152 In shell window 2
153
154 cd regress/bin
155 gdb bacula-xx    (where xx is the component you want to debug).
156 (possibly set a break point -- normally not)
157 run -s -f
158 (wait for the output to stop)
159
160 In shell window 1
161 (enter any character or simply a return)
162 (ignore the error message it prints complaining that the daemon
163 you are debugging is already running, which is in fact the case).
164
165
166 That is all there is to it.  The debugger window will get some
167 output and will stop waiting for input if anything goes wrong
168 like a seg fault.  At that point, you can enter commands.
169
170 The procedure avoids modifying the test scripts and trying to
171 find pids and the such.  If you want less debug output when
172 debugging, don't set REGRESS_DEBUG=1.
173
174 ===
175
176 Also, if you run from time to time on a computer that is not connected
177 to the network, please be sure that "hostname" is set to "localhost",
178 otherwise, your tests may fail because the hostname used by Bacula's
179 ./configure cannot be properly resolved.
180
181 Anyway, you can debug where it is happening in the source code using the 
182 following example.  For example, here I get the following backtrace:
183
184 ======= Backtrace: =========
185 /lib/libc.so.6[0xb7b9d6e1]
186 /lib/libc.so.6(cfree+0x89)[0xb7b9ed79]
187 /home/kern/bacula/regress/bin/bacula-fd[0x8082ae5]
188 /home/kern/bacula/regress/bin/bacula-fd[0x8082d58]
189 /home/kern/bacula/regress/bin/bacula-fd[0x80838ac]
190 /home/kern/bacula/regress/bin/bacula-fd[0x807aa3f]
191 /home/kern/bacula/regress/bin/bacula-fd[0x807ac29]
192 /home/kern/bacula/regress/bin/bacula-fd[0x804d188]
193 /lib/libc.so.6(__libc_start_main+0xdc)[0xb7b4ef9c]
194 /home/kern/bacula/regress/bin/bacula-fd[0x804cd21]
195
196 Now to convert this into something more meaningful, kill off any hung Bacula 
197 processes.  Note the one that was running -- above you see that it was 
198 bacula-fd, then bring the same binary up in the debugger.  Then start at the 
199 first bacula-fd line, and feed the hex number to gdb as follows:
200
201 info symbol 0x8082ae5
202 free_addresses(dlist*) + 53 in section .text
203
204 info symbol 0x8082d58
205 add_address(dlist**, IPADDR::i_type, unsigned short, int, char const*, char 
206 const*, char**) + 568 in section .text