copied from the actual english manual

[bacula/bacula] / regress / README

diff --git a/regress/README b/regress/README
index efd85e9e8eeb87c03eeae416df747fda0c436054..09dbc73bbefce3931902acd06a135e5135eff348 100644 (file)
--- a/regress/README
+++ b/regress/README
@@ -139,7 +139,68 @@ 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.
 
 copy, but those messages can be ignored.  This makes it reasonably easy
 to run any component or components under the debugger if necessary.
 

+Explicit example:
+
+In shell window 1.
+
+cd regress
+export REGRESS_DEBUG=1
+export REGRESS_WAIT=1
+tests/name-of-script-test
+(wait until it tells you to start the debugger)
+
+In shell window 2
+
+cd regress/bin
+gdb bacula-xx    (where xx is the component you want to debug).
+(possibly set a break point -- normally not)
+run -s -f
+(wait for the output to stop)
+
+In shell window 1
+(enter any character or simply a return)
+(ignore the error message it prints complaining that the daemon
+you are debugging is already running, which is in fact the case).
+
+
+That is all there is to it.  The debugger window will get some
+output and will stop waiting for input if anything goes wrong
+like a seg fault.  At that point, you can enter commands.
+
+The procedure avoids modifying the test scripts and trying to
+find pids and the such.  If you want less debug output when
+debugging, don't set REGRESS_DEBUG=1.
+
+===
+

 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.
 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