From owner-freebsd-current@FreeBSD.ORG Mon Apr 21 14:09:14 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89A1E37B401 for ; Mon, 21 Apr 2003 14:09:14 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F9EB43F3F for ; Mon, 21 Apr 2003 14:09:13 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id DB50850; Mon, 21 Apr 2003 16:09:12 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 3675678C66; Mon, 21 Apr 2003 16:09:12 -0500 (CDT) Date: Mon, 21 Apr 2003 16:09:12 -0500 From: "Jacques A. Vidrine" To: "Robin P. Blanchard" Message-ID: <20030421210912.GA89777@madman.celabo.org> References: <20030418163352.GC45899@madman.celabo.org> <20030418164437.GD45899@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030418164437.GD45899@madman.celabo.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: current@freebsd.org Subject: Re: Latest world NIS woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 21:09:14 -0000 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 , 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 , 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 http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se