Re: Troubles building world on stable/13

On 2022-Jan-21, at 16:02, Mark Millard <marklmi@yahoo.com> wrote:

> [I've switched back to messages with the original subject to
> avoid mixing the issues.]
> 
> On 2022-Jan-20, at 22:00, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On 2022-Jan-20, at 19:16, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> The last few attempts to build world on a Pi3 running stable/13 have
>>> stopped with something like:
>>> 
>>> --- all_subdir_lib/googletest/gmock ---
>>> ===> lib/googletest/gmock (all)
>>> Building /usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gmock-all.o
>>> --- gmock-all.o ---
>>> PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
>>> Stack dump:
>>> 0.      Program arguments: c++ -target aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -g -Wno-format-zero-length -fstack-protector-strong -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 -Qunused-arguments -I/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private -I/usr/src/contrib/googletest/googlemock/include -I/usr/src/contrib/googletest/googlemock -I/usr/src/contrib/googletest/googletest/include -g -std=c++11 -Wno-deprecated-declarations -Wno-deprecated-copy -Wno-c++11-extensions -c /usr/src/contrib/googletest/googlemock/src/gmock-all.cc -o gmock-all.o
>>> 1.      /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:1125:53: current parser token '{'
>>> 2.      /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:58:1: parsing namespace 'testing'
>>> --- all_subdir_lib/clang ---
>>> Building /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenEVEX2VEXTables.inc
>>> Building /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenFastISel.inc
>>> --- all_subdir_lib/googletest ---
>>> #0 0x0000000004112640 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
>>> #1 0x0000000004110a84 __cxx_atomic_store<CallbackAndCookie::Status> /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:996:5
>>> #2 0x0000000004110a84 store /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:1617:10
>>> #3 0x0000000004110a84 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:99:16
>>> #4 0x00000000040b4f08 HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76:5
>>> #5 0x00000000040b4f08 CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:389:51
>>> #6 0x00000000452bad80 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 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
>>> 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: /tmp/gmock-all-836ef8.cpp
>>> c++: note: diagnostic msg: /tmp/gmock-all-836ef8.sh
>>> c++: note: diagnostic msg: 
>>> 
>>> ********************
>>> *** [gmock-all.o] Error code 139
>> 
>> So: SIGSEGV (signal 11)
>> 
>>> make[6]: stopped in /usr/src/lib/googletest/gmock
>>> .ERROR_TARGET='gmock-all.o'
>>> .ERROR_META_FILE='/usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gmock-all.o.meta'
>>> .MAKE.LEVEL='6'
>>> MAKEFILE=''
>>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
>>> 
>>> make[4]: stopped in /usr/src/lib
>>> --- all_subdir_lib/clang ---
>>> 
>>> FWIW, filemon is enabled in /boot/loader.conf and the build command was
>>> make -j2 -DWITH_META_MODE  buildworld > buildworld.log
>>> 
>>> This doesn't appear to be ARM-specific in any obvious way, but it might
>>> be, so I'm posting here first.
>>> 
>> 
>> "uname -apKU" output from the building environment?
>> 
>> Commit identification for the /usr/src/ for stable/13
>> that is being built?
>> 
>> Any console messages? dmesg -a output of interest?
>> /var/log/messasges content of interest?
>> 
>> Any messages of interest somewhat earlier in the
>> buildworld.log ?
>> 
>> Does the problem repeat via using the files:
>> 
>> /tmp/gmock-all-836ef8.cpp
>> /tmp/gmock-all-836ef8.sh
>> 
>> on that RPi3? Elsewhere that has more resources, such
>> as more RAM?
> 
> I do not see anything between your:
> 
> Thank you, the script reports:
> branch: stable/13
> merge-base: d7b156672a48c37e1b8ce9b4ae28a46ecea55412
> merge-base: CommitDate: 2022-01-21 15:58:11 +0000
> d7b156672a4 (HEAD -> stable/13, freebsd/stable/13) zone.9: Remove documentation of non-existent NUMA configuration flags
> n249092 (--first-parent --count for merge-base)
> 
> and where I'm at for stable/13:
> 
> branch: stable/13
> merge-base: a5f69859956049b5153b0e1b67f8f4a99622dc6f
> merge-base: CommitDate: 2022-01-15 12:55:32 +0000
> a5f698599560 (HEAD -> stable/13, freebsd/stable/13) Ignore debugger-injected signals left after detaching
> n249004 (--first-parent --count for merge-base)
> 
> that would seem a likely explanation for why I
> did not see the problem when I built.
> 
> The same goes for between your stable/13-n248948-9418a626103
> starting point and where my stable/13 environment is at.
> 
> (In my case, I also build for poudriere and chroot trees,
> not just booting. So multiple builds are involved in the
> sequence.)
> 
> I've not come up with any ideas beyond the 2:
> 
> A) Trying the two files that failure produced for attempted
> reproduction of the problem (such as):
> 
> /tmp/gmock-all-836ef8.cpp
> /tmp/gmock-all-836ef8.sh
> 
> but in other system-clang 13 contexts to see if the problem is
> reproducible off that RPi3*.
> 
> B) Doing the /usr/obj/. . . cleanout and then a build-from-scratch
> attempt.
> 

I see that there is: http://www.zefox.net/~fbsd/rpi3/20220121/
with a .cpp and .sh pair (f5c28a).

I downloaded the two and tried the .sh under stable/13 and main
and got no failures. (But it was not an RPi* at all.)

For reference:

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37 main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400047 1300524

(The above is a chroot use into an area that can be used with
bectl to boot the machine.)

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37 main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400047 1400047


It does no good for me since I do not get a failure,
but you might try (instead of exectuing the .sh file)
(I used \'s to split the huge line):

lldb -- "/usr/bin/c++" "-cc1" "-triple" "aarch64-unknown-freebsd13.0" "-emit-obj" "--mrelax-relocations" \
"-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "gmock_main.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/obj/usr/src/arm64.aarch64/lib/googletest/gmock_main" \
"-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/obj/usr/src/arm64.aarch64/lib/googletest/gmock_main" \
"-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" "-fgnuc-version=4.2.1" \
"-fcxx-exceptions" "-fexceptions" "-vectorize-loops" "-vectorize-slp" "-faddrsig" \
"-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-x" "c++" "gmock_main-f5c28a.cpp"

and then "run" at the (lldb) prompt. It might stop and let you
get a backtrace (bt command) in addition to whatever it reports
about the stoppage.

In my environment the 2 references to:

/usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock_main

have no such directory available. In my context it would be:

/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/lib/googletest/gmock_main

But using the path instances for my context still did not
recreate the failure.

The command just added "lldb -- " in front of what was in the
.sh file, other than my line splits for the email.

===
Mark Millard
marklmi at yahoo.com