Advanced Troubleshooting

1. Troubleshooting network problems with rpc2tcpdump
2. Debugging with gdb

1. Troubleshooting network problems with rpc2tcpdump

rpc2tcpdump is the regular tcpdump, which is modified to decode rpc2 protocol headers. This makes it a very useful tool for analyzing why programs fail to work.

All traffic between venus and the Coda servers can be viewed using the following command:
# tcpdump -s120 -Trpc2 port venus or port venus-se

To identify problems with clog, for instance which server it is trying to get tokens from.
# tcpdump -s120 -Trpc2 port codaauth

2. Debugging with gdb

To be able to debug programs that use RVM, most coda related application will go into an endless sleep when something goes really wrong. They print their process-id in the log (f.i. venus.log or SrvLog), and a user can attach a debugger to the crashed, but still running, program.
# gdb /usr/sbin/venus `pidof venus`

This makes it possible to get a stack backtrace (where), go to a specific stack frame (frame x), or view the contents of variables, (print varname). By installing the coda sources in same place as where the binaries were initially built from, it is possible to view the surrounding code fragment from within the debugger using the list.

When using RedHat Linux rpms, you can install the sources in the right place by installing the coda source rpm file.
# rpm -i coda-x.x.x.src.rpm
# rpm -bp /usr/src/redhat/SPECS/coda.spec

On other platforms look at the paths reported in the backtrace and unpack the source tarball in the correct place.
(gdb) where
#0  CommInit () at /usr/local/src/coda-5.3.6/coda-src/venus/comm.cc:175
#1  0x80fa8c3 in main (argc=1, argv=0xbffffda4)
    at /usr/local/src/coda-5.3.6/coda-src/venus/venus.cc:168
(gdb) quit
# cd /usr/local/src
# tar -xvzf coda-5.3.6.tgz