X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=regress%2FREADME;h=5f5aad70aa44ea365409083eb609951ce8b94bee;hb=f976dd10e8a354e457c52193151a8406aab7a3c5;hp=f1ac81f6a176c01963ceb48b12cac5205046fa51;hpb=9dafe180afb908a56dc6fd0214f5d84079ddc95c;p=bacula%2Fbacula diff --git a/regress/README b/regress/README index f1ac81f6a1..5f5aad70aa 100644 --- a/regress/README +++ b/regress/README @@ -24,6 +24,11 @@ email address! 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 @@ -55,10 +60,22 @@ You can run all the disk based tests by doing: ./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. @@ -98,12 +115,59 @@ conf files, and you do not need a new copy of the source, you can simply do: 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 +