ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Konstantin Belousov]

On Wed, May 24, 2017 at 08:15:09AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote:
> > ...
> > > > I have updated /usr/src back to 318781, then started a new build.
> > > So are you building stock 318781, or did you reverted r318750 ?
> > 
> > Stock 318781 [*].  I revert as a (nearly) last resort. :-)
> > 
> > > > While it has not yet completed ">>> stage 4.2: building libraries", it
> > > > is well beyond the provious point of failure (again, building parts of
> > > > clang/libllvm).
> > > > 
> > > > I'm reporting now, as I'll need to head in to work fairly soon.  I
> > > > should be able to report definitively a bit later.
> > 
> > It's completed the ">>> stage 4.2: building libraries" part, and well
> > into ">>> stage 4.3: building everything".
> > 
> > * Save for my (usual) hacking of conf/newvers.sh a bit.
> > 
> > And now I really do need to head in to work.
> > ...
> 
> It completed successfully and a reboot shows:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017     root at freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64
> 

I performed a local experiment, first building sources from r318784
on a system where I did pre-commit test for ino64, updating the machine
to the result of it, then building sources of r318789 and again updating.

No SIGSEGV etc, so I think that the effects seen are due to build system.
rm -rf obj/* is the safest trick, I believe.