Whence you're in total trouble, a debugger is the way to help out. It is also the proper tool to report information back to the citadel development team (like Mozilla will do with its talkback facility). There are several instances of debuggers around, mdb / dbx for Solaris for example, but the one we will talk about here is the in the open source world most used GDB that you can also operate through DDD, KDevelop, Emacs or plain through its command line, which all of the above front ends also offer. We will show some basic operations here, you may want to search the gdb man page if you want to go deeper into detail.
Please remember that its always a good idea to check whether your troubles persist with the SVN Head revision (after doing a backup of your data).

These will produce allmost meaningless output in gdb, just maybe the addr2line utility can gather some information from that. However, the better method is to use an unstripped binary (the install process does this), that you will find inside your source tree. If you like to do stepping and not want gdb to jump back and forth, compile it with -ggdb -o0 compiler flags.

Citadel brings you untripped/citserver, which matches your active citserver. Use this to analyse your core files.

On Linux this can be achieved with the ulimit command which is documented in the bash man page.

ulimit -c 999999

The core files are created in the working directory. Be careful, they can grow and eat up your disk space.
Making the whole system create core files on crashes in a central folder can be achieved like that:

local to citadel by editing /etc/init.d/citadel or /etc/init.d/webcit and add in the second line:

Nobody's perfect. Valgrind is the most decent tool around these days to detect tiny flaws in programs and bust memory leaks. (the process growing constantly because of it forgets about memory it demanded from the system) We use valgrind to ensure the quality of citadel. This is how you can run it:

Sometimes code doesn't work as expected in special situations, a program develops hotspots. Profilers can help here, gprof does in our case. It needs special binaries, heres how to create them:
If you want to create them via the deb-build, just do

Now you're equipped with those special binaries, run them, produce the high load situation you've experienced, and stop them regularly afterwards, so they can write their 'gmon.out' file containing the profiling raw data. WebCit can be shut down with 'killall -HUP webserver', citserver will finish its job with 'sendcommand down'.