bug-hurd
[Top][All Lists]
Advanced

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

Re: nss is broken


From: Marcus Brinkmann
Subject: Re: nss is broken
Date: Wed, 31 Jul 2002 15:26:40 +0200
User-agent: Mutt/1.4i

On Tue, Jul 30, 2002 at 06:19:57PM +0200, Marcus Brinkmann wrote:
> However, something is still broke: NSS.

Actually, it might not be NSS but dlopen in general.  NSS is just the first
test case we encounter (but then, it is the only one I tried).

I have a good idea of what happens now, but not why it happens.  Here is
what I saw in gdb:

First, everything runs normal up to _dl_map_object_from_fd.  Note that
_dl_map_object opens the file for us.  I traced it down all the way to the
__open in open_verify, which opened the file successfully on port 117 and
allocated the file descriptor 7 for it, which was returned and used
subsequently to verify that this is an ELF file.

Then, _dl_map_object_from_fd continues to operate, and if I saw it
correctly, the first time through it succeeded, including the __fxstat64.
Later on, it was called again on the same object, it seems.  I am not sure
what exactly happens inbetween, but the second time it was called with fd 7,
it did not use the normal __fxstat64, but the one from
sysdeps/mach/hurd/dl-sysdep.c.

int weak_function
__fxstat64 (int vers, int fd, struct stat64 *buf)
{
  error_t err;

  assert (vers == _STAT_VER);

  err = __io_stat ((mach_port_t) fd, buf);
  if (err)
    return __hurd_fail (err);

  return 0;
}

However, this one calls __io_stat on the file descriptor itself, not on the
port (I guess this is a hack that is only used for the linker itself, which
seems to avoid creating real fd's for mach ports, and just uses the port
number for the fd, as this is consistent with the rest of the dl-sysdep
file).  However, calling io_stat on number 7 (instead 117, or whatever else)
only leads to a EMACH_SEND_INVALID_DEST, which is converted into an EIEIO,
which leads to the linker error "cannot stat shared object" in
_dl_map_object_from_fd.

I hope this is enough information to fix it, as my excitement to debug bugs
in the linker has reached an all-year low :)  It seems that in loading a
shared object the above weak function is used in favor of the real
implementation that should be available somewhere.  Dunno how this can
happen.  If you need to know more about who calls _dl_map_object_from_fd the
second time and for which object, let me know, and I will provide more
details.

Thanks,
Marcus




-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/



reply via email to

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