Erratic crash in install(1) on BeagleBone

[Tim Kientzle]

I occasionally try doing a full native buildworld/installworld
directly on BeagleBone as a system stability test and to
verify the native toolchain.

Hasn't succeeded yet….  but it does seem to be getting closer.

Latest problem is a random and infrequent crash in install.

This is with -CURRENT r241077.

Here's a typical occurrence:

install -s -o root -g wheel -m 444     libreadline.so.8 /lib
pid 10313 (install), uid 0: exited on signal 10 (core dumped)
*** [_libinstall] Signal 10
Stop in /usr/src/gnu/lib/libreadline/readline.

I've seen it happen about four times so far:
   * Always in install.
   * Installing different files
   * After the installworld has been running for a while
   * Always at the same code in the install program
   * Not reproducible installing a single directory; I've only seen
     it when doing a full installworld or 'make install' over a large
     portion of the tree

In particular, it always crashes in the install() function
when trying to access the 'gid' variable at the point marked
below:

        /*
         * Set owner, group, mode for target; do the chown first,
         * chown may lose the setuid bits.
         */
        if ((gid != (gid_t)-1 && gid != to_sb.st_gid) ||
            (uid != (uid_t)-1 && uid != to_sb.st_uid) ||
            (mode != (to_sb.st_mode & ALLPERMS))) {
                /* Try to turn off the immutable bits. */
                if (to_sb.st_flags & NOCHANGEBITS)
                        (void)fchflags(to_fd, to_sb.st_flags & ~NOCHANGEBITS);
        }

// XXXXX CRASHES READING gid RIGHT HERE XXXXXX
        if ((gid != (gid_t)-1 && gid != to_sb.st_gid) ||
            (uid != (uid_t)-1 && uid != to_sb.st_uid))
                if (fchown(to_fd, uid, gid) == -1) {
                        serrno = errno;
                        (void)unlink(to_name);
                        errno = serrno;
                        err(EX_OSERR,"%s: chown/chgrp", to_name);
                }

Notice that there's an identical access to the 'gid' variable
a few lines above.  Something Very Strange must be
happening between those two points.

Pulling the core dump into gdb doesn't show any
obvious problems.  In particular, I can inspect all
the relevant areas of memory and they all look right
in gdb.

If anyone has ideas about this (including ideas about
how to debug it), I'm interested.

Cheers,

Tim