Clang segfaults on RPI3 in Alpha9 during buildworld

[bob prohaska]

On Wed, Oct 17, 2018 at 10:18:18AM -0700, Mark Millard wrote:
> 
> 
> 
> When clang fails it sometimes produces text like:
> 
> cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
> cc: note: diagnostic msg: 
> ********************
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> cc: note: diagnostic msg: /tmp/control-696205.c
> cc: note: diagnostic msg: /tmp/control-696205.sh
> cc: note: diagnostic msg: 
> 
> ********************
> *** [control.lo] Error code 1
> 
> 
> The .c and .sh files are intended to help reproduce the problem
> without being part of a grander operation like buildworld. (The
> names of the .c and .h vary from run to run.)
> 
> Did your example produce such messages? If yes, you may want to
> provide some sort of access to the files. if no, you may want
> to report that.
> 
> Sometimes the .c is big enough to justify compression if it is to
> go into, say, a FreeBSD bugzilla submittal. Some people bundle
> the two files into one compressed file.
> 

Clang did all of those things, I put the diagnostic files at
http://www.zefox.net/~fbsd/rpi3/clang_trouble/
in case they're worth looking at.

It turned out that simply restarting buildworld with -DNO_CLEAN permitted 
a run to completion. For the moment it looks like it's probably not a clang 
issue. Sources are updated and a clean-start rebuild is running now.

This configuration is new: All storage is on a 128GB Samsung microSD card,
arranged in a single partition with 4GB of swap at the end per the Handbook 17.3:

mmcsd0: 128GB <SDHC ED4QT 3.0 SN 9B9A5304 MFG 05/2018 by 27 SM> at mmc0 50.0MHz/4bit/65535-block 

root at www:/usr/src # gpart show mmcsd0s2
=>        0  249980985  mmcsd0s2  BSD  (119G)
          0         57            - free -  (29K)
         57  241133568         1  freebsd-ufs  (115G)
  241133625      38856            - free -  (19M)
  241172481    8808504         2  freebsd-swap  (4.2G)

It's surprising that Samsung overstates the capacity by ~8GB.

The kernel complains about too much swap, but that hasn't caused
recognizable problems in the past, on either Pi3 or Pi2. At one
point two simultaneous -j4 buildworlds were started by mistake, 
pushing swap use over 2GB with vm.pageout_oom_seq: 2048 and no 
distress apart from "indefinite wait...." warnings.

Thanks for reading!

bob prohaska