From owner-freebsd-current@FreeBSD.ORG Thu Oct 12 18:04:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 3B0EC16A407 for ; Thu, 12 Oct 2006 18:04:24 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D0BD43E38 for ; Thu, 12 Oct 2006 18:02:07 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k9CI1qQC061175 for ; Thu, 12 Oct 2006 13:01:53 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <452E8313.7000808@centtech.com> Date: Thu, 12 Oct 2006 13:01:55 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.7 (X11/20060923) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/2026/Thu Oct 12 01:47:06 2006 on mh2.centtech.com X-Virus-Status: Clean Subject: yp related ls core dumps (amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 12 Oct 2006 18:04:24 -0000 I have two systems, both running FreeBSD 6-STABLE (amd64) (one is freshly installed from -BETA2 CD, the other is cvs-up'ed from a few weeks ago). Both these systems will make ls (and several other tools) core dump when accessing a directory that had it's gid's from yp. I'm not sure what exactly the trigger is, but if I remove the yp related line from /etc/group it works just fine (uid's are resolved, but of course gid's are not). If I put the line back in, I get: # ls -al /nfsmounts/filesystem/directory/ Segmentation fault: 11 (core dumped) However an 'ls -aln' of that same directory always works ok. Here's a snippet of the trailing edge of a ktrace on the failing ls: ...snip... 0x0000 452f a45e 0000 0000 0000 0002 0001 86a4 0000 0002 0000 0003 0000 |E/.^......................| 0x001a 0000 0000 0000 0000 0000 0000 0000 0000 000c 6365 6e74 7465 6368 |..................ypdomain| 0x0034 2e63 6f6d 0000 000b 6772 6f75 702e 6279 6769 6400 0000 0003 3630 |.com....group.bygid.....60| 0x004e 3800 |8.| 957 ls RET sendto 80/0x50 957 ls CALL kevent(0x7,0x51e110,0x1,0x7fffffffd800,0x1,0x7fffffffd820) 957 ls RET kevent 1 957 ls CALL recvfrom(0x5,0x51e134,0x900,0,0,0) 957 ls GIO fd 5 read 516 bytes 0x0000 452f a45e 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 |E/.^......................| 0x001a 0001 0000 01e2 6c6f 6769 633a 2a3a 3630 383a 6272 656e 7462 2c62 |......group:*:608:user1,u| 0x01ee 2c72 6172 6f73 652c 7374 6572 6e2c 766d 6f68 616e 0000 |,user2,user3,user4..| 957 ls RET recvfrom 516/0x204 957 ls CALL close(0x7) 957 ls RET close 0 957 ls CALL gettimeofday(0x7fffffffd900,0) 957 ls RET gettimeofday 0 957 ls CALL gettimeofday(0x7fffffffd930,0) 957 ls RET gettimeofday 0 957 ls CALL close(0x6) 957 ls RET close 0 957 ls PSIG SIGSEGV SIG_DFL 957 ls NAMI "ls.core" I've replaced any real users/groups with fake ones above. gdb says something about: #0 0x000000080095272b in _fseeko () from /lib/libc.so.6 #1 0x0000000800952b78 in fseeko () from /lib/libc.so.6 #2 0x000000080091fde9 in __gr_parse_entry () from /lib/libc.so.6 #3 0x000000080094b971 in nsdispatch () from /lib/libc.so.6 #4 0x000000080091efe4 in getgrgid_r () from /lib/libc.so.6 #5 0x000000080091f0b0 in getgrgid_r () from /lib/libc.so.6 #6 0x00000008008e3aa6 in group_from_gid () from /lib/libc.so.6 #7 0x0000000000402271 in display (p=0x50b100, list=0x50b200, options=48) at ls.c:704 #8 0x0000000000402ace in traverse (argc=1, argv=0x0, options=48) at ls.c:527 #9 0x0000000000402e44 in main (argc=1, argv=0x7fffffffecb8) at ls.c:457 This same setup causes no issues on a 32bit system. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------