(In reply to wisdom from comment #0)

There have been prior reports on the list for the same
type of gtest-all.cc failures. This was in Jan./Feb.
starting with:

https://lists.freebsd.org/archives/freebsd-arm/2022-January/000857.html

Starting subject: "Troubles building world on stable/13"

This was on a RPi3B (not mine). It turns out that the
failure point can vary but is in an analogous type of
context in every case I've looked at. The build would
even on occasion work.

The only way I was able to repeat the problem was to use a
copy of the system-clang compiler executable from that
RPi3B. (Not a whole toolchain substitution, just using the
one file in my environment.)

I used what was analogous to your files:

c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.cpp
c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.sh

as a test case, avoiding needing a buildworld to be
involved.

I tried and failed to isolate the failure, even though
I could get repetitions of the problem. The closest I
got to useful evidence was documented in:

https://lists.freebsd.org/archives/freebsd-arm/2022-February/000979.html

That was also my notice that I'd given up on trying to
analyze the issue.

(In reply to wisdom from comment #0)

I'll note that, to my knowledge, no official FreeBSD
buildworld artifacts ever produced the problem.
Substituting an appropriate extracted system-clang
from an artifact build allowed the buildworld to
work in the original context, if I remember right.

But the compiler the system ended up with after
installation and rebooting had the problem again,
if I remember right.

(I did not have access to the RPi3B that
had the problem originally and none of my
activity was using the same system builds.
No system compiler I built ever demonstrated
the problem but the copy from the original
system did demonstrate the problem in my
context.)

Given your "raspi.isogo.dyndns.org" naming, I
gather your context is on some RPi* model. It
might be appropriate to list as much detail
as you can for future comparison-of-context
activities that might occur.

(In reply to Mark Millard from comment #2)

Messages to the console or the like could also
be relevant, if there are messages at the
time or somewhat before the failure.

I'll note that using stable/13 at or after:
13ba1d283676 to try the builds would provide
much better messages about any OOM (Out Of
Memory) kill activity (if any).

Of course, to get to that point may require
installation of some other stable build than
you are running, such as via a snapshot's or
artifact's materials. 11045f1b7 predates
13ba1d283676 by some amount. Then clean
buildworld buildkernel and install, and try
buildworld build kernel again based on the
locally built system, including system-clang.

I read the thread that starting with "Troubles building world on stable/13".  It seems almost same situation as you mentioned.

"raspi.isogo.dyndns.org" is a Raspberry Pi 3B.
It has 1GB RAM and 3GB swap.
The build had been executed with "rm -rf /usr/obj/usr && make -j1 buildworld"
No errors (including OOM) or incident worthy menthions earlier in the buildworld log and /var/log/messages.

# swapinfo -m
Device          1M-blocks     Used    Avail Capacity
/dev/label/swap      3599       26     3573     1%
# freebsd-version -ru
13.1-PRERELEASE
13.0-STABLE
# uname -apKU
FreeBSD raspi.isogo.dyndns.org 13.1-PRERELEASE FreeBSD 13.1-PRERELEASE #14 stable/13-11045f1b7: Mon Feb 28 12:09:56 JST 2022     root@raspi# uname -apKU
FreeBSD raspi0.michi.org 13.1-PRERELEASE FreeBSD 13.1-PRERELEASE #14 stable/13-11045f1b7: Mon Feb 28 12:09:56 JST 2022     root@raspi0.michi.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1300526 1300523
:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1300526 1300523
# sysctl kern.elf64.aslr.enable
kern.elf64.aslr.enable: 0
# lldb -- `tail -n 1 gtest-all-f81d5b.sh | sed -e 's/"//g'`
(lldb) target create "/usr/bin/c++"
Current executable set to '/usr/bin/c++' (aarch64).
(lldb) settings set -- target.run-args  "-cc1" "-triple" "aarch64-unknown-freebsd13.0" "-emit-obj" "--mrelax-relocations" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "gtest-all.cc" "-mrelocation-model" "static" "-mframe-pointer=non-leaf" "-fno-rounding-math" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "generic" "-target-feature" "+neon" "-target-abi" "aapcs" "-fallow-half-arguments-and-returns" "-debug-info-kind=standalone" "-dwarf-version=4" "-debugger-tuning=gdb" "-fcoverage-compilation-dir=/usr/src/lib/googletest/gtest" "-sys-header-deps" "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" "-Wno-format-y2k" "-W" "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" "-Wcast-qual" "-Wwrite-strings" "-Wswitch" "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" "-Wredundant-decls" "-Wmissing-variable-declarations" "-Wno-empty-body" "-Wno-string-plus-int" "-Wno-unused-const-variable" "-Wno-error=unused-but-set-variable" "-Wno-deprecated-declarations" "-Wno-deprecated-copy" "-Wno-c++11-extensions" "-std=c++11" "-fdeprecated-macro" "-fdebug-compilation-dir=/usr/src/lib/googletest/gtest" "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" "-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" "-fcolor-diagnostics" "-vectorize-loops" "-vectorize-slp" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-x" "c++" "gtest-all-f81d5b.cpp"
(lldb) run
Process 66795 launched: '/usr/bin/c++' (aarch64)
Process 66795 stopped
* thread #1, name = 'c++', stop reason = signal SIGSEGV: invalid address (fault address: 0x1)
    frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] getPointer at PointerIntPair.h:59:58
   56
   57     explicit PointerIntPair(PointerTy PtrVal) { initWithPointer(PtrVal); }
   58
-> 59     PointerTy getPointer() const { return Info::getPointer(Value); }
   60
   61     IntType getInt() const { return (IntType)Info::getInt(Value); }
   62
(lldb) up 1
frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] isNull at PointerUnion.h:172:43
   169
   170    /// Test if the pointer held in the union is null, regardless of
   171    /// which type it is.
-> 172    bool isNull() const { return !this->Val.getPointer(); }
   173
   174    explicit operator bool() const { return !isNull(); }
   175
(lldb) bt
* thread #1, name = 'c++', stop reason = signal SIGSEGV: invalid address (fault address: 0x1)
    frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] getPointer at PointerIntPair.h:59:58
  * frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] isNull at PointerUnion.h:172:43
    frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at TinyPtrVector.h:166:13
    frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at ParsedAttr.h:873:40
    frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at SemaDeclAttr.cpp:8449:16
    frame #5: 0x000000000317e784 c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3
(lldb) up 1
frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at TinyPtrVector.h:166:13
   163    bool empty() const {
   164      // This vector can be empty if it contains no element, or if it
   165      // contains a pointer to an empty vector.
-> 166      if (Val.isNull()) return true;
   167      if (VecTy *Vec = Val.template dyn_cast<VecTy*>())
   168        return Vec->empty();
   169      return false;
(lldb) bt
* thread #1, name = 'c++', stop reason = signal SIGSEGV: invalid address (fault address: 0x1)
    frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] getPointer at PointerIntPair.h:59:58
    frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] isNull at PointerUnion.h:172:43
  * frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at TinyPtrVector.h:166:13
    frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at ParsedAttr.h:873:40
    frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at SemaDeclAttr.cpp:8449:16
    frame #5: 0x000000000317e784 c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3
(lldb) up 1
frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at ParsedAttr.h:873:40
   870    using SizeType = decltype(std::declval<VecTy>().size());
   871
   872  public:
-> 873    bool empty() const { return AttrList.empty(); }
   874    SizeType size() const { return AttrList.size(); }
   875    ParsedAttr &operator[](SizeType pos) { return *AttrList[pos]; }
   876    const ParsedAttr &operator[](SizeType pos) const { return *AttrList[pos]; }
(lldb) bt
* thread #1, name = 'c++', stop reason = signal SIGSEGV: invalid address (fault address: 0x1)
    frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] getPointer at PointerIntPair.h:59:58
    frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] isNull at PointerUnion.h:172:43
    frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at TinyPtrVector.h:166:13
  * frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at ParsedAttr.h:873:40
    frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at SemaDeclAttr.cpp:8449:16
    frame #5: 0x000000000317e784 c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3
(lldb) up 1
frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at SemaDeclAttr.cpp:8449:16
   8446 void Sema::ProcessDeclAttributeList(Scope *S, Decl *D,
   8447                                     const ParsedAttributesView &AttrList,
   8448                                     bool IncludeCXX11Attributes) {
-> 8449   if (AttrList.empty())
   8450     return;
   8451
   8452   for (const ParsedAttr &AL : AttrList)
(lldb) bt
* thread #1, name = 'c++', stop reason = signal SIGSEGV: invalid address (fault address: 0x1)
    frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] getPointer at PointerIntPair.h:59:58
    frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] isNull at PointerUnion.h:172:43
    frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at TinyPtrVector.h:166:13
    frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at ParsedAttr.h:873:40
  * frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at SemaDeclAttr.cpp:8449:16
    frame #5: 0x000000000317e784 c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3
(lldb) up 1
frame #5: 0x000000000317e784 c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3
   8534     }
   8535   }
   8536
-> 8537   ProcessDeclAttributeList(S, Specialization, Attr);
   8538
   8539   // Add alignment attributes if necessary; these attributes are checked when
   8540   // the ASTContext lays out the structure.
(lldb) bt
* thread #1, name = 'c++', stop reason = signal SIGSEGV: invalid address (fault address: 0x1)
    frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] getPointer at PointerIntPair.h:59:58
    frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] isNull at PointerUnion.h:172:43
    frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at TinyPtrVector.h:166:13
    frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined] empty at ParsedAttr.h:873:40
    frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at SemaDeclAttr.cpp:8449:16
  * frame #5: 0x000000000317e784 c++`::ActOnClaTemplateSpecialization() at SemaTemplate.cpp:8537:3
(lldb) ^D
#  git -C /usr/src status -uno
On branch stable/13
Your branch is up to date with 'freebsd/stable/13'.

nothing to commit (use -u to show untracked files)
# git -C /usr/src diff
# fetch http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base.txz
...
# mkdir ~/chroot
# tar -xpf base.txz -C ~/chroot
# cp -paRx /tmp/gtest-all-f81d5b.* ~/chroot/tmp/
# /usr/bin/c++ -v
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
Target: aarch64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
# ~/chroot/usr/bin/c++ -v
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
Target: aarch64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /root/chroot/usr/bin
# chroot ~/chroot
# set prompt='chroot # '
chroot # cd /tmp
chroot # ls -l
total 14416
-rw-r--r--  1 root  wheel  7308936 Jan 28 12:41 gtest-all-f81d5b.cpp
-rw-r--r--  1 root  wheel     4527 Jan 28 12:41 gtest-all-f81d5b.sh
chroot # sh ./gtest-all-f81d5b.sh
chroot # sh ./gtest-all-f81d5b.sh
chroot # ls -l
total 24784
-rw-r--r--  1 root  wheel  7308936 Jan 28 12:41 gtest-all-f81d5b.cpp
-rw-r--r--  1 root  wheel  5246192 Mar  7 01:58 gtest-all-f81d5b.o
-rw-r--r--  1 root  wheel     4527 Jan 28 12:41 gtest-all-f81d5b.sh
chroot # exit
# umount ~/chroot/dev
# cd /tmp
# ls -l gtest-all-f81d5b.*
-rw-r--r--  1 root  wheel  7308936 Jan 28 12:41 gtest-all-f81d5b.cpp
-rw-r--r--  1 root  wheel     4527 Jan 28 12:41 gtest-all-f81d5b.sh
# sh ./gtest-all-f81d5b.sh
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
....
#5 0x00000000452bad80 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
Segmentation fault (core dumped)
# sed -e 'sX/usr/bin/c++X/root/chroot/usr/bin/c++X' gtest-all-f81d5b.sh > ./gtest-all-f81d5b-chrooted.sh
# sh ./gtest-all-f81d5b-chrooted.sh
# ls -l gtest-all-f81d5b*
-rw-r--r--  1 root  wheel     4557 Mar  7 02:14 gtest-all-f81d5b-chrooted.sh
-rw-r--r--  1 root  wheel  7308936 Jan 28 12:41 gtest-all-f81d5b.cpp
-rw-r--r--  1 root  wheel  5246192 Mar  7 02:15 gtest-all-f81d5b.o
-rw-r--r--  1 root  wheel     4527 Jan 28 12:41 gtest-all-f81d5b.sh
# mv /usr/bin/c++ /usr/bin/c++.orig
# cp -paRx /root/chroot/usr/bin/c++ /usrr/bin/c++
# rm -f gtest-all-f81d5b.o
# sh ./gtest-all-f81d5b.sh
# ls -l gtest-all-f81d5b.sh
-rw-r--r--  1 root  wheel     4557 Mar  7 02:14 gtest-all-f81d5b-chrooted.sh
-rw-r--r--  1 root  wheel  7308936 Jan 28 12:41 gtest-all-f81d5b.cpp
-rw-r--r--  1 root  wheel  5246192 Mar  7 02:20 gtest-all-f81d5b.o
-rw-r--r--  1 root  wheel     4527 Jan 28 12:41 gtest-all-f81d5b.sh
#

Adding my observation of this failure to build world on a RPi 2 with 1GB RAM.

FreeBSD pi2 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC arm

Building releng/13.2 from git.

--- CodeGen/CGObjCGNU.o ---
#0 0x03d70ad8 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:573:7
#1 0x03d6e9a8 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:0:5
#2 0x03d2163c HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:79:5
#3 0x03d2163c CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:392:51
#4 0x253060f0 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
c++: error: clang frontend command failed with exit code 139 (use -v to see invocation)
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
Target: armv7-unknown-freebsd13.2-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /var/tmp/CGObjCGNU-ac5a32.cpp
c++: note: diagnostic msg: /var/tmp/CGObjCGNU-ac5a32.sh
c++: note: diagnostic msg:

********************
*** [CodeGen/CGObjCGNU.o] Error code 139

make[6]: stopped in /usr/src/lib/clang/libclang

(In reply to Vick Khera from comment #5)

Console messages or dmesg -a output or /var/log/messages content
associated with the failure time frame? How much swap space was
active [hopfeully via swap partition(s)]?

I'll note that may different types of problems produce:

"c++: error: clang frontend command failed with exit code 139"

so that message does not indicate much about similarity.

The original report was for compiling:

/usr/src/contrib/googletest/googletest/src/gtest-all.cc

with it being captured as: /tmp/gtest-all-f81d5b.cpp

Your report is for /var/tmp/CGObjCGNU-ac5a32.cpp and so
may well be different. There is also:

FreeBSD clang version 13.0.0
vs.
FreeBSD clang version 14.0.5

and the FreeBSD version differences.

Console messages or dmesg -a output or /var/log/messages from
the time frame leading to the failure looks the best way to
get a clue about what was going on.