Re: Help me in tracking a bug in NFS

[olafBuddenhagen]

Hi,

On Fri, Apr 11, 2008 at 02:28:37AM +0530, Madhusudan C.S wrote:

> I am just going through the source files in nfs directory in Hurd
> source tree. There are two directories with names nfs and nfsd.

nfsd is the NFS daemon, i.e. the server; the other is the client. In
general, translators use the same name for the source directory as the
binary you invoke in settrans...

> Can anyone of you please help me tracing out where this problem might
> be happening. I request you to give some basic idea behind this or
> clues so that I can continue.

Some ideas that come to mind: You could for example look through the
involved code paths, trying to find something suspicious that you want
to examine more closely. This probably means starting at the source code
of rmdir, to see which system calls it does. From there, you could go to
glibc, trying to find the implementation of these system calls, to see
what RPCs they map to. Now you can look at the matching entry points in
the implementation of the NFS translator.

Or run rpctrace on rmdir to see directly which RPCs it invokes.

Instead of just staring at the code, you could trace the individual bits
with gdb. There is a page somewhere in the wiki about tracing
translators...

Another (probably more effective) approach is to try tracing it
backwards: Look where the error message comes from. Again, you could
step through rmdir with gdb, trying to find the place where the error is
printed, and conclude from there which system call set the error code.
Now you could trace the system call to find out which RPC is invoked,
and try to look through the implementation in the translator for a place
which sets the particular error code.

Or instead of tracing rmdir with gdb, you could just check what error
code the error message corresponds to (I think the error list is
somewhere in the Hurd source code... though it might be glibc too, not
sure); and then run rpctrace on rmdir and try to find the RPC that
returns this error code.

Or you could compare the rpctrace output of rmdir with the "/" and
without it, trying to determine which RPCs could be affected by the
difference, and then take a closer look at the implementation of these.

And so on. You can mix these approaches in various ways, trying to
isolate the problem. Use your imagination :-)

Once you attempted everything you can think of, let us know what you
did, what you found out, and what problems you encountered that
prevented you to get further... Feel free to ask if you are not sure how
to do anything of what I described above, preferably on IRC.

-antrik-