(unknown charset) Re: Latest world NIS woes

On Fri, Apr 18, 2003 at 11:44:37AM -0500, Jacques A. Vidrine wrote:
> On Fri, Apr 18, 2003 at 11:33:52AM -0500, Jacques A. Vidrine wrote:
> > One would suspect.  Is the YP server a FreeBSD box?  I guess not,
> > since your crypt'd password seems to be included in the standard map?
> 
> I built a map with the password included, same results:
> 
>   # ypcat passwd   
>   ypuser1:*:9001:9001:YP User 1:/nonexistent:/sbin/nologin
>   ypuser2:*:9002:9002:YP User 2:/nonexistent:/sbin/nologin
>   robin:wasCryptdPass:20292:30028::/home/robin:/bin/bash
>   # id -u robin
>   20292
>   # id -g robin
>   30028
>   # id robin
>   uid=20292(robin) gid=30028(NSS) groups=30028(NSS)
> 
> (I grabbed the `NSS' group line from the ktrace output.  I also
> saw that you had no nsswitch.conf, so I configured likewise to test.)
> 
> > Possibly I have a bug in passwd.adjunct map handling -- I haven't been
> > able to test that.
> 
> > I'll grab your ktrace, and also peek to see what I might have done
> > wrong with passwd.adjunct.
> 
> Well, I can see from your ktrace that passwd.adjunct is not involved.
> 
> I've not been able to reproduce the problem here.  Can you send me a
> backtrace?


For those that were following this thread, this is what I found:

I could not reproduce Robin's issue, despite using the same data for
the entries he was interested in.  So he let me jump on his machine to
look closer.  I found something very odd:


  Breakpoint 3, wrap_getpwnam_r (key={name = 0x28135d00 "", uid = 672357632}, pwd=0x28135d00, buffer=0x28135d00 "", bufsize=672357632, res=0x28135d00)
      at /usr/src/lib/libc/gen/getpwent.c:398
  398             return (getpwnam_r(key.name, pwd, buffer, bufsize, res));
  (gdb) bt    
  #0  wrap_getpwnam_r (key={name = 0x28135d00 "", uid = 672357632}, pwd=0x28135d00, buffer=0x28135d00 "", bufsize=672357632, res=0x28135d00)
      at /usr/src/lib/libc/gen/getpwent.c:398
  #1  0x280c912b in getpw (fn=0x280c91a0 <wrap_getpwnam_r>, key={name = 0xbfbffc71 "robin", uid = 3217030257}) at /usr/src/lib/libc/gen/getpwent.c:377
  #2  0x280c92a9 in getpwnam (name=0x28135d00 "") at /usr/src/lib/libc/gen/getpwent.c:424
  #3  0x08049164 in who (u=0x281307bc "øF\f") at /usr/src/usr.bin/id/id.c:331
  #4  0x08048b96 in main (argc=1, argv=0x281307bc) at /usr/src/usr.bin/id/id.c:135
  #5  0x080488f5 in _start (ap=0xbfbffc50 "/usr/obj.g/usr/src/usr.bin/id/id") at /usr/src/lib/csu/i386-elf/crt1.c:104
  (gdb) frame 1
  #1  0x280c912b in getpw (fn=0x280c91a0 <wrap_getpwnam_r>, key={name = 0xbfbffc71 "robin", uid = 3217030257}) at /usr/src/lib/libc/gen/getpwent.c:377
  377                     rv = fn(key, &pwd, pwd_storage, pwd_storage_size, &res);
  (gdb) frame 0
  #0  wrap_getpwnam_r (key={name = 0x28135d00 "", uid = 672357632}, pwd=0x28135d00, buffer=0x28135d00 "", bufsize=672357632, res=0x28135d00)
      at /usr/src/lib/libc/gen/getpwent.c:398
  398             return (getpwnam_r(key.name, pwd, buffer, bufsize, res));
  (gdb) print &key
  Address requested for identifier "key" which is in register $eax
  (gdb) print &pwd
  Address requested for identifier "pwd" which is in register $eax
  (gdb) 


It is as if the generated code had a register aliasing problem.  I
noticed that he was building with CPUTYPE=i686, and I asked him to
retry with NO_CPUTYPE_FLAGS.  The problem went away.

Nonetheless, I cannot reproduce the issue here, even with
CPUTYPE=i686.

Any GCC gurus have comments?  For some reason I want to suspect issues
with passing a `union' as an argument.  I'm going to have Robin try a
version that does not do that (it was only being used for type safety)
and see if we get similar results.

Cheers,
-- 
Jacques A. Vidrine <nectar_at_celabo.org>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
jvidrine_at_verio.net     .  nectar_at_FreeBSD.org  .          nectar_at_kth.se