> I am looking at the nfsd, but I am getting traps and failures in: > > sleep -> mach_msg -> mach_msg_trap
Please be more specific. Can you show us the gdb backtrace and so forth? What does "traps and failures" mean exactly? > (where -> is read "calls"). I would like to look at the definition > of these two routines. I don't really intend to build libc, though I > suppose I can if necessary. It should not be necessary if you just want to read the source. There is a single libc source for all GNU systems, both Linux and Hurd. The current development can be found at http://sourceware.cygnus.com, but you probably just want to get the debian source package of glibc that goes with the binary package you are using. If you get that source, and use the glibc_dbg package (libc0.2_dbg? something like that) of binaries with debugging symbols (it's huge, but downloading it still probably faster than building glibc from source), then gdb should just be happy to show you the libc source directly. The *dbg packages install debugging libraries in /lib/libc_debug (though the loaded segments of the binaries are identical to the non-dbg packages, they just have the debugging symbols as well), so you need to use LD_LIBRARY_PATH=/lib/libc_debug (or via set env in gdb) when starting the programs you want to debug. All that said, it is unlikely that reading sleep and mach_msg will shed any specific light on the problems you are seeing. I certainly wouldn't discourage you from reading the source, but for a problem with nfsd I'm quite sure that looking for a bug in sleep is a red herring.
