c++: error: unable to execute command: Killed
c++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Thread model: posix
c++: 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.
c++: note: diagnostic msg:
Created attachment 196006 [details]
Second attachment was not accepted because of size (has 14MB, max. accepted 1MB).
Most likely, you are running out of memory. Try lowering your make -j level, or adding some more swap (or memory :).
(In reply to Dimitry Andric from comment #3)
From other issues we have seen on aarch64 and small memory amd64 VM's adding swap is rarely the solution to this, you either have to add memory or reduce -j level.
(In reply to Rodney W. Grimes from comment #4)
You need to add non-flash swap typically to make any headway, although reducing -j is more effective. Spinning disks suffer much less from these issues, but are slower. Also, on rpi3 there appears to be a hanging bug in the USB stack which can sometimes be triggered. The arm64 issues stem from crappy nand and bad drivers causing undue (multi-second) delays. But the original poster is running on amd64 where that's not an issue because most people aren't putting swap on crappy SD cards, crappy USB thumb drives and our SATA drivers there are much, much more mature and resilient.
(In reply to Warner Losh from comment #5)
While Bob P.'s reports were with large gstat reporting large
ms/w and/or ms/r, Trev had made reports of getting the problem
without gstat indicating multi-second delays (averages for some
time intervals) and having lots of swap still available, starting
(But Trev only provided short segments of the records in
messages instead of posting the whole logs somewhere. This
Note to avoid misinterpretation: I am in general agreement with
the following as appropriate experiments . . .
"You need to add non-flash swap"
"Spinning disks suffer much less from these issues"
although I would explicitly add that there are SSD-based USB
drives and at least some of these might be about as good as
using a direct SATA SSD environment with good SSDs. (Correct
me if I'm wrong for some reason.)
Notes on testing:
Having records from, say, periodic gstat runs, is a good cross
check in all cases. Having the information-reporting patches
from Mark Johnston are appropriate for testing as well.
http://www.zefox.net/~fbsd/rpi3/swaptests/tools/ has various
things that have been used in testing. But batchqueue.patch
did not pan out and likely should be avoided. Similarly for
config_options. The readme is what talks about:
The rest are patches for reporting of additional information
during operation. These are likely more important than the
gstat ms/w and ms/r records.
The context for the patches is recent head, not 11.x .
(In reply to Mark Millard from comment #6)
[This is extracted from another context that
involved the Pine64+ 2GB.]
As of updating to -r337400 the Pine64+ 2GB no
longer will boot from the e.MMC on the microsd
adapter card. (I switched to tracking fully
modern dts use, u-boot, etc.)
So I tried a build via a USB SSD as the root
file system and swap partition. As reported in:
it failed with an Out Of Memory kill. (More detail there.
I did not adjust vm.pageout_oom_seq .)
This should have avoided I/O latency problems being
involved. (That message is part of a long on-going
thread tied to OOM kills, most of the reports involving
large I/O latencies being involved.)
Very little swap was observed to be in use. This was
a context with Mark Johnston's reporting patches in
place, but they only reported the kill itself, not
waiting for I/O or such.
I can not change the Affects Only Me status.
Dimitry Andric is possibly the wrong assignee:
not the compiler's problem if the system did an
Out Of Memory kill of a process.
Other bugzilla's are: 227609 230402, not just this