Summary: | clang crashes on the port graphics/drawpile on 15 CURRENT armv7: Assertion failed: ((!TII->analyzeBranch(*PrevBB, TBB, FBB, Cond) || !PrevBB->canFallThrough()) && "Unexpected block with un-analyzable fallthrough!"), function buildCFGChains | ||
---|---|---|---|
Product: | Base System | Reporter: | Yuri Victorovich <yuri> |
Component: | misc | Assignee: | freebsd-toolchain (Nobody) <toolchain> |
Status: | Closed Overcome By Events | ||
Severity: | Affects Only Me | CC: | dim, jfc, markj, marklmi26-fbsd |
Priority: | --- | ||
Version: | 15.0-CURRENT | ||
Hardware: | Any | ||
OS: | Any | ||
URL: | https://pkg-status.freebsd.org/ampere2/data/main-armv7-default/p4be48457f87b_s4347ef6050/logs/Drawpile-2.1.20_4.log |
Description
Yuri Victorovich
2024-01-12 06:28:03 UTC
You did not report the explicit assertion failure notice. So, starting a little earlier in the file for the extraction: Assertion failed: ((!TII->analyzeBranch(*PrevBB, TBB, FBB, Cond) || !PrevBB->canFallThrough()) && "Unexpected block with un-analyzable fallthrough!"), function buildCFGChains, file /usr/local/poudriere/jails/main-armv7/usr/src/contrib/llvm-project/llvm/lib/CodeGen/MachineBlockPlacement.cpp, line 2816. 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++ -DHAVE_CONFIG_H -DHAVE_DNSSD -DHAVE_GIFLIB -DHAVE_UPNP -DHAVE_WEBM -DQTCOLORPICKER_STATICALLY_LINKED -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_WIDGETS_LIB -I/wrkdirs/usr/ports/graphics/drawpile/work/.build/src/desktop -I/wrkdirs/usr/ports/graphics/drawpile/work/Drawpile-2.1.20/src/desktop -I/wrkdirs/usr/ports/graphics/drawpile/work/.build/src/desktop/drawpile_autogen/include -I/wrkdirs/usr/ports/graphics/drawpile/work/.build -I/wrkdirs/usr/ports/graphics/drawpile/work/Drawpile-2.1.20/src/desktop/../libclient -I/wrkdirs/usr/ports/graphics/drawpile/work/Drawpile-2.1.20/src/desktop/bundled/QtColorWidgets/include -isystem /usr/local/include/qt5 -isystem /usr/local/include/qt5/QtNetwork -isystem /usr/local/include/qt5/QtCore -isystem /usr/local/lib/qt5/mkspecs/freebsd-clang -isystem /usr/local/include/KF5/KArchive -isystem /usr/local/include/KF5 -isystem /usr/local/include/KF5/KDNSSD -isystem /usr/local/include/qt5/QtGui -isystem /usr/local/include -isystem /usr/local/include/qt5/QtWidgets -isystem /usr/local/include/qt5/QtMultimedia -isystem /usr/local/include/qt5/QtSvg -Wall -pedantic -Wextra -std=c++11 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -fPIC -MD -MT src/desktop/CMakeFiles/drawpile.dir/toolwidgets/brushsettings.cpp.o -MF src/desktop/CMakeFiles/drawpile.dir/toolwidgets/brushsettings.cpp.o.d -o src/desktop/CMakeFiles/drawpile.dir/toolwidgets/brushsettings.cpp.o -c /wrkdirs/usr/ports/graphics/drawpile/work/Drawpile-2.1.20/src/desktop/toolwidgets/brushsettings.cpp All information I know is in the URL link. (In reply to Yuri Victorovich from comment #2) So you put the burden of finding the basic description for the problem on the folks that would try to process your submittal instead of including it in the description. When an explicit assertion failure notice is present, I'd suggest always including it in the description and having the summary line mention "assertion failure" (it is more specific than "crashes" and indicates some about the kind of information available). (In reply to Mark Millard from comment #3) The idea that missing assertion was not intentional is a very evasive idea. (In reply to Yuri Victorovich from comment #4) Sorry if my note seemed to indicate that you had the intent of omitting the assertion instead of your possibly just being a little rushed and, so, not finding possibly better information for the description. I try to defer my compiler-failure submittals until after I've had some time to find out if there is an assertion failure notice to include in the description if there is not time for that up front. > 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/brushsettings-800a79.cpp
> c++: note: diagnostic msg: /tmp/brushsettings-800a79.sh
Is it possible to include these files in the report?
I don't have access to the arm machines where failures occur. (In reply to Mark Johnston from comment #6) Not only are the official package builders limited to logs, but poudiere builds in general do not preserve those files: no material from /tmp is in the compressed tar generated if one has it configured to generate those tar files on failure. The builder's /tmp likely does not last long after the failure. But I've vague memories of some command line option for clang/clang++ to make those failure files go in the local directory instead, so inside what the tar file covers. That still requires a separate build attempt in a different environment. (In reply to Mark Johnston from comment #6) I found my old notes in another bugzilla entry: QUOTE(outer) FYI, relative to potential build infrastructure behavior, clang/clang++ has: QUOTE -fcrash-diagnostics-dir=<dir> Specify where to write the crash diagnostics files; defaults to the usual location for temporary files. END QUOTE So redirecting to someplace that poudriere(-devel) with -w includes in the (compressed) tar archive for build failures is a possibility. END QUOTE(outer) Sometimes touching a Makefile with the likes of (partial diff output): QUOTE +CFLAGS+= -fcrash-diagnostics-dir=. +CPPFLAGS+= -fcrash-diagnostics-dir=. END QUOTE allows for that capture in the tar file for the failure if it has been enabled. This seems to have been fixed by the update to Drawpile 2.2.0. Is there any value in keeping the bug open? (In reply to John F. Carr from comment #10) This is up to @freebsd-toolchain to decide. If there aren't any repro files I think it is hard to do anything. |