yp related ls core dumps (amd64)

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.
------------------------------------------------------------------------