Since ~05/16/2022 amd64 build for math/vtk8 crashes clang. 1. <eof> parser at end of file 2. Optimizer #0 0x0000000004a64c90 (/usr/bin/c+++0x4a64c90) #1 0x0000000004a62f58 (/usr/bin/c+++0x4a62f58) #2 0x0000000004a141a4 (/usr/bin/c+++0x4a141a4) #3 0x0000000004a1438c (/usr/bin/c+++0x4a1438c) #4 0x0000000089b1d3a8 (/lib/libthr.so.3+0x293a8) c++: error: clang frontend command failed with exit code 134 (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: aarch64-unknown-freebsd14.0
Are there preprocessed .cpp and .sh files available?
(In reply to Dimitry Andric from comment #1) I only got fallout messages.
I don't have access to aarch64 machines which can build ports, so somebody(TM) should maybe write a feature for poudriere that can lift out these crash reports... ;-)
(In reply to Dimitry Andric from comment #3) Downloading the log file from one of the recent failed builds and looking farther back in the log than what has been reported so far I find an "Assertion failed" notice: Assertion failed: (!getDef() && "VPValue is not a live-in; it is defined by a VPDef inside a VPlan"), function getLiveInIRValue, file /usr/local/poudriere/jails/main-arm64/usr/src/contrib/llvm-project/llvm/lib/Transforms/Vectorize/VPlanValue.h, line 188. 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: /usr/bin/c++ -DVTK_IN_VTK -DvtkGeovisCore_EXPORTS -I/wrkdirs/usr/ports/math/vtk8/work/.build/Geovis/Core . . . (skipping many -I options) . . . -I/wrkdirs/usr/ports/math/vtk8/work/.build/ThirdParty/libproj/vtklibproj/src -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fPIC -fvisibility=hidden -std=c++11 -MD -MT Geovis/Core/CMakeFiles/vtkGeovisCore.dir/vtkGeoInteractorStyle.cxx.o -MF Geovis/Core/CMakeFiles/vtkGeovisCore.dir/vtkGeoInteractorStyle.cxx.o.d -o Geovis/Core/CMakeFiles/vtkGeovisCore.dir/vtkGeoInteractorStyle.cxx.o -c /wrkdirs/usr/ports/math/vtk8/work/VTK-8.2.0/Geovis/Core/vtkGeoInteractorStyle.cxx 1. <eof> parser at end of file 2. Optimizer #0 0x0000000004a64c90 (/usr/bin/c+++0x4a64c90) #1 0x0000000004a62f58 (/usr/bin/c+++0x4a62f58) #2 0x0000000004a141a4 (/usr/bin/c+++0x4a141a4) #3 0x0000000004a1438c (/usr/bin/c+++0x4a1438c) #4 0x000000008a3383a8 (/lib/libthr.so.3+0x293a8) c++: error: clang frontend command failed with exit code 134 (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: aarch64-unknown-freebsd14.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/vtkGeoInteractorStyle-010919.cpp c++: note: diagnostic msg: /tmp/vtkGeoInteractorStyle-010919.sh c++: note: diagnostic msg: May be that will help a little.
I tried a build targeting armv7 and it completed okay. I replicated the failure for targeting aarch64, using bulk -w -i . But the -i only shows the following in /tmp : # ls -Tldt /tmp/* -rw-r--r-- 1 root wheel 0 Jun 25 10:08:38 2022 /tmp/su-to-portbuild drwxr-xr-x 2 root wheel 7 Jun 25 10:08:03 2022 /tmp/packages Looking: it executes in /usr/local/poudriere/data/.m/main-CA72-default/ref/ and no numbered main-CA72-default/*/ exist at the time. So the relevant tmp/ has been cleaned out already. I was able to expand the -w created archive and re-execute the failing command and get the (or a) failure. I'll see about trying to get a .txz of the .cpp and .sh from tmp/ as an attachment. (No web browser or GUI for the aarch64 machine involved. So things are less direct. I'm not aware of a way to directly add the attachment to this bugzilla entry from such a context.) Note: My buildworld has clang built without assertions but it still fails. Thus the assertion failure would be unlikely to be a false positive.
Created attachment 234935 [details] Contains the /tmp/*.cpp and /tmp/*.sh from my replication effort