[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fakeroot status

From: Roland McGrath
Subject: Re: fakeroot status
Date: Tue, 14 May 2002 21:06:44 -0400 (EDT)

> I don't get it.  I have verified that exec correctly increases the dtable
> size from 3 to 4, and adds the file port to it.  I set a breakpoint at
> S_exec_exec, and first it is hit executing "bashbug" with dtablesize 3,
> and then it is hit executing /bin/sh /dev/fd/3 with dtablesize being 4,
> and dtable[0]
> - dtable[3] look reasonable.

What do you mean by "look reasonable"?  They are valid send rights?
That doesn't tell you what kind of peropen each is, or to what file.

> OTOH, I don't quite understand that code.  For example, I don't see where
> exactly the (new) file descriptors are added to the new task.  

The file_exec call on the interpreter (sh) is where it goes from there.
That in turn results in an ordinary exec_exec of the interpreter file.  
If you're unclear on what happens after that, read exec.c:do_exec,
S_exec_startup_get_info, and libc/hurd/hurdstartup.c.

> However, I verified that the /dev/fd/3 mechanism works in a non-fakeroot
> environment.

Hmm.  Since it is getting the node to the underlying file in dtable[3],
there shouldn't be any difference from fakeroot in how accessing /dev/fd/3
works (unless the /dev/fd magic isn't working right).  Have you checked the
interpreter process to see whether it has no fd 3 or has a port on which an
RPC returns EBADF?  You could tell from rpctrace whether it makes an RPC
that returns EBADF after looking up /dev/fd/3, or you could just attach gdb
to the program and step through its open of /dev/fd/3 (while you have the
exec server stopped, fg your gdb bash and attach it to the task to bump its
suspend count, then let the exec complete and you can set bkpts).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]