From 5c61aed7ff357f3e301f4b3c64249d65b6094830 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/hanki_pank#f42c5" Date: Tue, 26 Oct 2010 01:58:40 -0700 Subject: [PATCH] --- AFSLore/debugging.mdwn | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 AFSLore/debugging.mdwn diff --git a/AFSLore/debugging.mdwn b/AFSLore/debugging.mdwn new file mode 100644 index 0000000..9b34287 --- /dev/null +++ b/AFSLore/debugging.mdwn @@ -0,0 +1,39 @@ +## Debugging Servers + +Servers are multithreaded, so if one hangs, it is most interesting to see
+what the different threads are doing.
+Using gdb, you can get a stack trace of all threads
+(provided, you compiled your server with "--enable-debug"). + +First, we need to get the pid and the full path of the server (e.g. fileserver): + + PID=`ps -eaf | grep fileserver | grep -v grep | awk '{print $2}'` + SRV_PATH=`ps -eaf | grep fileserver | grep -v grep | awk '{print $9}'` + + +Then we need to attach the gdb and make it display the stack of all threads : + + gdb --batch --eval-command="thread apply all where" $SRV_PATH $PID > /tmp/threads.log + +After this you might use the attached script "threadLogParser.py" to display the intersting threads. + +e.g. + + threadLogParser.py -g /tmp/threads.log -e rx_GetCall + +displays only threads which are not in this boring rx_GetCall (threads are waiting for a new call). + + +## Debugging Clients + +Low-level debugging of a client can be done using "fstrace".
+Unfortunately, this produces a lot of output, so it is not easy +to catch an intermittent error-condition with "fstrace". + +The attached script "ClientTracing.py" gives you the opportunity to continuously run a fstrace,
+where the output is stored in rotating log-files. + +In case of an external-event (the existence of a predefined file), it saves this log and does not overwrite +it again.
+Thus, all you need to do is to write a script which creates this predefined file, when that event happens. + -- 1.9.4