Re: bin/40574: netbsd-4 builds fail on netbsd-5 hosts (nbmtree issues)

[Greg Oster <oster%cs.usask.ca@localhost>]

The following reply was made to PR bin/40574; it has been noted by GNATS.

From: Greg Oster <oster%cs.usask.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/40574: netbsd-4 builds fail on netbsd-5 hosts (nbmtree issues) 
Date: Sat, 07 Feb 2009 21:45:48 -0600

 adrianp%stindustries.net@localhost writes:
 > >Number:         40574
 > >Category:       bin
 > >Synopsis:       netbsd-4 builds fail on netbsd-5 hosts (nbmtree issues)
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    bin-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Sat Feb 07 18:15:00 +0000 2009
 > >Originator:     Adrian Portelli
 > >Release:        5.0_BETA
 > >Organization:
 > >Environment:
 > 5.0_BETA (amd64)
 > >Description:
 > I upgraded my build box to netbsd-5 and have started to try and do some
 > builds of the netbsd-4{,-0} branches.  All the builds fail at the same
 > point regardless of architecture (sparc,sparc64,amd64,i386).  With a
 > little bit of digging I think it's mtree that's causing the segfault.
 > If I manually run the command and replace 'nbmtree' with just 'mtree' it
 > works fine.
 > 
 > gdb on the core file from nbmtree gives up the following if it helps:
 > 
 > Program terminated with signal 11, Segmentation fault.
 > #0  0x00007f7ffd9c838a in strlen () from /usr/lib/libc.so.12
 > (gdb) bt
 > #0  0x00007f7ffd9c838a in strlen () from /usr/lib/libc.so.12
 > #1  0x00007f7ffd9c10cd in __vfprintf_unlocked () from /usr/lib/libc.so.12
 > #2  0x00007f7ffd9c21e4 in vfprintf () from /usr/lib/libc.so.12
 > #3  0x00007f7ffd9bd4de in printf () from /usr/lib/libc.so.12
 > #4  0x000000000040521c in dump_nodes ()
 > #5  0x00000000004050aa in main ()
 > (gdb)
 > 
 > 
 > >How-To-Repeat:
 > Try to build a netbsd-4* release on a netbsd-5* host.
 > 
 > Don't know if the same issue exists on a netbsd-5* i386 host.
 
 It doesn't. 
 
 But I can replicate this on amd64 XEN_DOMU from today's 5.0_RC1 when 
 trying to build for netbsd-4 i386.
 
 In a nutshell, the prototype for user_from_uid() (and others) 
 don't get pulled in because they are protected by 
 #if defined(_NETBSD_SOURCE)
 in /usr/include/pwd.h and that #define isn't set when building mtree 
 as a tool.  If one looks closely when doing the build, one sees:
 
 /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c: In function 
'dump_nodes':
 /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:334: warning: 
assignment makes pointer from integer without a cast
 /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:341: warning: 
assignment makes pointer from integer without a cast
 
 (among other similar errors in mtree).  If I hack the Makefile a bit 
 I can get a version that crashes and has symbols.  What I end up with 
 is:
 
 Core was generated by `mtree'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x00007f7ffd9caf7a in strlen () from /usr/lib/libc.so.12
 (gdb) where
 #0  0x00007f7ffd9caf7a in strlen () from /usr/lib/libc.so.12
 #1  0x00007f7ffd9c3c2d in __vfprintf_unlocked () from /usr/lib/libc.so.12
 #2  0x00007f7ffd9c4d44 in vfprintf () from /usr/lib/libc.so.12
 #3  0x00007f7ffd9c003e in printf () from /usr/lib/libc.so.12
 #4  0x0000000000406a88 in dump_nodes (dir=0x40f13f "", root=0x7f7ffd81d180, 
     pathlast=0) at /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:335
 #5  0x0000000000405f42 in main (argc=0, argv=0x7f7fffffdc38)
     at /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/mtree.c:211
 (gdb) up
 #1  0x00007f7ffd9c3c2d in __vfprintf_unlocked () from /usr/lib/libc.so.12
 (gdb) up
 #2  0x00007f7ffd9c4d44 in vfprintf () from /usr/lib/libc.so.12
 (gdb) up
 #3  0x00007f7ffd9c003e in printf () from /usr/lib/libc.so.12
 (gdb) up
 #4  0x0000000000406a88 in dump_nodes (dir=0x40f13f "", root=0x7f7ffd81d180, 
     pathlast=0) at /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:335
 335                                     printf("uname=%s ", name);
 (gdb) list
 330                     if (MATCHFLAG(F_TYPE))
 331                             printf("type=%s ", nodetype(cur->type));
 332                     if (MATCHFLAG(F_UID | F_UNAME)) {
 333                             if (keys & F_UNAME &&
 334                                 (name = user_from_uid(cur->st_uid, 1)) != 
NULL)
 335                                     printf("uname=%s ", name);
 336                             else
 337                                     printf("uid=%u ", cur->st_uid);
 338                     }
 339                     if (MATCHFLAG(F_GID | F_GNAME)) {
 (gdb) print name
 $1 = 0xfffffffffd4b2704 <Address 0xfffffffffd4b2704 out of bounds>
 
 which, of course, is going to go 'boom' when passed to printf.
 
 The fix, of course, is to pull in the correct prototype for 
 user_from_uid() and assorted other functions (there are other build 
 errors if one looks close -- I can provide a list if needed), but I'm 
 not sure what the right mechanism is for doing that in the land of build 
 tools...
 
 Later...
 
 Greg Oster