If you are using SQLite, make sure that depkgs is pre-built if it
isn't already: (cd your-depkgs; make sqlite).
+Note, if you use any database other than SQLite, be sure it is not
+your production database because Bacula will delete all the tables
+and recreate them. With SQLite, a new different database is created,
+so it will not affect your production system.
+
Using the .conf file, you can now select between any Catalog type:
SQLite, SQLite3, MySQL, or PostgreSQL. Be aware, however, if you
use an installed database on a production server, running these
./do_file
+The disk based tests are totally separate from any production
+system, provided you have configured the database appropriately
+as noted above.
+
You can run all the disk and most of the tape tests by doing:
./do_all
+======== Important !!! ============
+When running the tape tests, Bacula will write on any tape that
+is in the tape drive that you have configured. If it is a production
+Bacula tape, it will be destroyed. If you have configured an Autochanger,
+Bacula will write on the tapes in slots 1 and 2 thus destroying any
+information on those tapes, even if they are Bacula production tapes.
+===================================
+
Each of the above calls one or more scripts. By looking at the
scripts available in this directory, you can see that there are a number
of options for running tests.
make sed
Debugging failed tests:
-The simplest thing to do is to edit tests/xxxx where xxxx is the name of
-the test, and change the line "set_debug 0" to "set_debug 1". If the test has
-not been updated to have the debug variable, please notify Kern, and I
-will be happy to fix it -- I am upgrading them one at a time.
+Prior versions required editing the tests/xxxx and changing a debug flag.
+However, that has been replaced by two environment variables:
+
+ REGRESS_DEBUG
+ REGRESS_WAIT
+
+If you define REGRESS_DEBUG, e.g.
+
+ REGRESS_DEBUG=1
+ export REGRESS_DEBUG
+
+then run a test, it will display the job and debug output.
+
+If you define REGRESS_WAIT, the script will stop and request:
+
+Start Bacula under debugger and enter anything when ready ...
+
+At this point, you can start any of the daemons under the debugger,
+then answer the message by entering any character. The script will
+then continue. For any daemon or daemons that you have manually started,
+you will see an error message when the script attempts to run a second
+copy, but those messages can be ignored. This makes it reasonably easy
+to run any component or components under the debugger if necessary.
Also, if you run from time to time on a computer that is not connected
to the network, please be sure that "hostname" is set to "localhost",
otherwise, your tests may fail because the hostname used by Bacula's
./configure cannot be properly resolved.
+
+Anyway, you can debug where it is happening in the source code using the
+following example. For example, here I get the following backtrace:
+
+======= Backtrace: =========
+/lib/libc.so.6[0xb7b9d6e1]
+/lib/libc.so.6(cfree+0x89)[0xb7b9ed79]
+/home/kern/bacula/regress/bin/bacula-fd[0x8082ae5]
+/home/kern/bacula/regress/bin/bacula-fd[0x8082d58]
+/home/kern/bacula/regress/bin/bacula-fd[0x80838ac]
+/home/kern/bacula/regress/bin/bacula-fd[0x807aa3f]
+/home/kern/bacula/regress/bin/bacula-fd[0x807ac29]
+/home/kern/bacula/regress/bin/bacula-fd[0x804d188]
+/lib/libc.so.6(__libc_start_main+0xdc)[0xb7b4ef9c]
+/home/kern/bacula/regress/bin/bacula-fd[0x804cd21]
+
+Now to convert this into something more meaningful, kill off any hung Bacula
+processes. Note the one that was running -- above you see that it was
+bacula-fd, then bring the same binary up in the debugger. Then start at the
+first bacula-fd line, and feed the hex number to gdb as follows:
+
+info symbol 0x8082ae5
+free_addresses(dlist*) + 53 in section .text
+
+info symbol 0x8082d58
+add_address(dlist**, IPADDR::i_type, unsigned short, int, char const*, char
+const*, char**) + 568 in section .text
+
projects / bacula / bacula / blobdiff