Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1832695 - clang-12 crashes when used with clazy plugin
Summary: clang-12 crashes when used with clazy plugin
Alias: None
Product: Fedora
Classification: Fedora
Component: clazy
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jan Grulich
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-05-07 05:36 UTC by Cajus Pollmeier
Modified: 2021-05-12 05:43 UTC (History)
3 users (show)

Fixed In Version: clazy-1.9-1.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-05-12 05:43:02 UTC
Type: Bug

Attachments (Terms of Use)

Description Cajus Pollmeier 2020-05-07 05:36:41 UTC
Description of problem:

I'm using clazy to do some static code analysis in our CI. When I upgrade the  base image to F32 for the latest an greatest compilers, the clazy run doesn't succeed anymore.

Version-Release number of selected component (if applicable):


How reproducible:

I'm unable to create a reproducer with the clang call using -gen-reproducer. If you need it, I'd need some assistance here.

Steps to Reproduce:

$ LANG=C clazy -Qunused-arguments -c -pipe -Wno-padded -gen-reproducer -isystem /home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include -O3 -fPIC -std=gnu++1z -Wall -Wextra -ffunction-sections -fdata-sections -D_REENTRANT -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/home/cajus/prj/src/lib/model -I/home/cajus/prj/build/src/lib/model -I/home/cajus/prj/src/lib/core -I/home/cajus/prj/external/libbar/include/libbar -I../rpc -I/home/cajus/prj/src/lib/ep/epcommon -I/home/cajus/prj/src/lib/util -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include/QtGui -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include/QtNetwork -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include/QtCore -I/home/cajus/prj/build/src/lib/model -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/mkspecs/linux-clang -o cfgvaluehandler.o /home/cajus/prj/src/lib/model/common/cfgvaluehandler.cpp

Actual results:

0.      Program arguments: /usr/bin/clang++ -Qunused-arguments -Xclang -load -Xclang -Xclang -add-plugin -Xclang clazy -Qunused-arguments -c -pipe -Wno-padded -gen-reproducer -isystem /home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include -O3 -fPIC -std=gnu++1z -Wall -Wextra -ffunction-sections -fdata-sections -D_REENTRANT -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/home/cajus/prj/src/lib/model -I/home/cajus/prj/build/src/lib/model -I/home/cajus/prj/src/lib/core -I/home/cajus/prj/external/libbar/include/libbar -I../rpc -I/home/cajus/prj/src/lib/ep/epcommon -I/home/cajus/prj/src/lib/util -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include/QtGui -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include/QtNetwork -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/include/QtCore -I/home/cajus/prj/build/src/lib/model -I/home/cajus/.conan/data/qt/5.14.2/foo/stable/package/0ad110c3e5e45998fcbaffcabbffff28cca43b24/mkspecs/linux-clang -o cfgvaluehandler.o /home/cajus/prj/src/lib/model/common/cfgvaluehandler.cpp
1.      /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/type_traits:34:2: current parser token 'if'
 #0 0x00007fc3cb41b6ee llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib64/
 #1 0x00007fc3cb4199c4 llvm::sys::RunSignalHandlers() (/usr/lib64/
 #2 0x00007fc3cb358b38 (/usr/lib64/
 #3 0x00007fc3ca641ab0 __restore_rt (/usr/lib64/
 #4 0x00007fc3d00917d5 clang::Preprocessor::HandleMacroExpandedIdentifier(clang::Token&, clang::MacroDefinition const&) (/usr/lib64/
 #5 0x00007fc3d00a6551 clang::Preprocessor::HandleIdentifier(clang::Token&) (/usr/lib64/
 #6 0x00007fc3d003f524 clang::Lexer::LexIdentifier(clang::Token&, char const*) (/usr/lib64/
 #7 0x00007fc3d0041f1e clang::Lexer::LexTokenInternal(clang::Token&, bool) (/usr/lib64/
 #8 0x00007fc3d00aa08f clang::Preprocessor::Lex(clang::Token&) (/usr/lib64/
 #9 0x00007fc3d007fe1b clang::Preprocessor::EvaluateDirectiveExpression(clang::IdentifierInfo*&) (/usr/lib64/
#10 0x00007fc3d006f103 clang::Preprocessor::HandleIfDirective(clang::Token&, clang::Token const&, bool) (/usr/lib64/
#11 0x00007fc3d007a819 clang::Preprocessor::HandleDirective(clang::Token&) (/usr/lib64/
#12 0x00007fc3d0042237 clang::Lexer::LexTokenInternal(clang::Token&, bool) (/usr/lib64/
#13 0x00007fc3d00aa08f clang::Preprocessor::Lex(clang::Token&) (/usr/lib64/
#14 0x00007fc3d00af7d4 clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib64/
#15 0x00007fc3d16ded69 clang::FrontendAction::Execute() (/usr/lib64/
#16 0x00007fc3d169ac4d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib64/
#17 0x00007fc3d1754d3c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib64/
#18 0x00005591b114b440 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/bin/clang+++0x17440)
#19 0x00005591b1149a94 (/usr/bin/clang+++0x15a94)
#20 0x00007fc3d13c86f9 (/usr/lib64/
#21 0x00007fc3cb358c47 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/usr/lib64/
#22 0x00007fc3d13cad67 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const (/usr/lib64/
#23 0x00007fc3d139f46d clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/usr/lib64/
#24 0x00007fc3d139f9d6 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/usr/lib64/
#25 0x00007fc3d13a7ef3 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/usr/lib64/
#26 0x00005591b1145b86 main (/usr/bin/clang+++0x11b86)
#27 0x00007fc3ca62c042 __libc_start_main (/usr/lib64/
#28 0x00005591b1146c1e _start (/usr/bin/clang+++0x12c1e)
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
clang-10: error: failing because '-gen-reproducer' is used
clang version 10.0.0 (Fedora 10.0.0-1.fc32)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang-10: note: diagnostic msg: PLEASE submit a bug report to  and include the crash backtrace, preprocessed source, and associated run script.
clang-10: error: unable to execute command: Aborted (core dumped)
clang-10: note: diagnostic msg: Error generating preprocessed source(s).
free(): double free detected in tcache 2
/usr/bin/clazy: line 137: 425227 Aborted                 (core dumped) ${CLANGXX:-clang++} -Qunused-arguments -Xclang -load -Xclang $ClazyPluginLib -Xclang -add-plugin -Xclang clazy $ExtraClangOptions "$@"

Expected results:

Should compile cleanly.

Comment 1 "FeRD" (Frank Dana) 2020-09-01 12:25:40 UTC
I'm having what I'm sure is the same issue with the current F32 clazy-1.6-3.fc32.x86_64, and it seems to have to do with the include path clazy is using.

In my case, I'm building a CMake project which can be compiled successfully with either g++ or clang++, but when I try to use the recommended `cmake -DCMAKE_CXX_COMPILER=clang ...` CMake fails to even configure the build tree, claiming that clazy "can't compile a simple test program".

So after giving up there, I configured the CMake project to build with clang++ and export its compile commands for clazy-standalone consumption:

pushd build
CLANGXX=/usr/bin/clang++ clazy-standalone -p build/compile_commands.json src/sourcefile.cpp
In file included from .../src/sourcefile.cpp:31:
In file included from .../include/sourcefile.h:34:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/memory:64:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/allocator.h:46:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/x86_64-redhat-linux/bits/c++allocator.h:33:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/ext/new_allocator.h:33:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/new:41:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/exception:147:
In file included from /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/exception_ptr.h:38:
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/cxxabi_init_exception.h:38:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
1 error generated.
Error while processing .../src/sourcefile.cpp.

It strikes me as EXTREMELY odd that code building with a Clang-based tool would be referencing the GCC headers in /usr/bin/../lib/gcc/x86_64-redhat-linux/10/, even indirectly. But I see a similar path in the output Cajus posted:

1.      /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/type_traits:34:2: current parser token 'if'

Comment 2 "FeRD" (Frank Dana) 2020-09-01 12:26:41 UTC
*sigh* This:

when I try to use the recommended `cmake -DCMAKE_CXX_COMPILER=clang ...`

should of course have read:

when I try to use the recommended `cmake -DCMAKE_CXX_COMPILER=clazy ...`

Comment 3 "FeRD" (Frank Dana) 2020-09-01 14:41:35 UTC
So, after building my own clazy from and installing it to /home/ferd/, then UNINSTALLING the system clazy package, I was able to get CMake to use /home/ferd/bin/clazy as the CMAKE_CXX_COMPILER and it appears to be functioning properly.

One thing I notice is that clazy-1.6-3.fc32.x86_64 is linked against LLVM 9, and some strace output when I was debugging this /seemed/ like it was really expecting to be running clang++ 9 as a result. Among other things, there were /usr/lib64/clang/9* paths it was trying to search. But those don't exist anymore, on an F32 install with clang-10.0.0-2.fc32.x86_64.

Perhaps the issue is that the F32 clang++ has been upgraded to Clang 10 / LLVM 10?

The clazy I built was, of course, compiled with clang++ (aka clang++-10). As a result, my is linked with (I uninstalled llvm9.0-libs along with clazy.)

Comment 4 Fedora Program Management 2021-04-29 16:24:23 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 "FeRD" (Frank Dana) 2021-04-29 22:04:09 UTC
I think this can probably be closed, right Cajus? Fedora 33 clazy is linked with, same version that's used by the current clang++-11 compiler binary. As a result, clazy seems to work fine in F33, and presumably (hopefully!) will continue to work correctly in F34.

Comment 6 Cajus Pollmeier 2021-04-30 05:39:45 UTC
F34 has clang 12 by default. I didn't change my CI Docker file (which compiles the latest and greatest clazy itself), so I didn't notice whether it works now or not.

Just gave it a shot, and - no - it's still impossible to build the project with the F34 provided clazy. It works fine with a self compiled one (or i.e. with the one extracted from the AppImg).

Additionally clazy in F34 could be updated to 1.9 instead of 1.7.x.

Comment 7 "FeRD" (Frank Dana) 2021-05-02 00:14:28 UTC

Mmm, I see that F34 clazy is still linked with LLVM 11, but as you say clang has been updated to version 12 so they're once again incompatible. That's a strange choice, especially when everything was working in F33.

Comment 8 "FeRD" (Frank Dana) 2021-05-03 16:38:30 UTC
I'm putting together a set of specfile changes to build clazy against LLVM-12, which I'll submit as PRs against both the rawhide and f34 branches at — hopefully we can get clazy updated to again be functional in F34.

I'm surprised, though, that there don't seem to be either an rpm-macros-llvm or rpm-macros-clang package that could be pulled in to make the clazy package depend on the _specific_ version of LLVM that matches the system's default clang... because clazy builds are most definitely tied to a specific clang version, and should be rebuilt as chained dependencies whenever clang gets updated. The versioned dependencies that would signal that in the package metadata don't seem to be present, currently, which is I think why clazy keeps falling out of step with the system clang.

I'll ask around on the packaging list, see if there's any interest in publishing a set of rpm-macros-clang / rpm-macros-llvm for situations like this.

Comment 9 "FeRD" (Frank Dana) 2021-05-03 18:13:33 UTC
(In reply to "FeRD" (Frank Dana) from comment #8)
> I'll ask around on the packaging list, see if there's any interest in
> publishing a set of rpm-macros-clang / rpm-macros-llvm for situations like
> this.

Comment 10 "FeRD" (Frank Dana) 2021-05-03 18:29:47 UTC
@jgrulich if you're following this, my fork of the clazy packaging repo has a clang-12 branch which contains changes to update clazy to version 1.9, and to patch it so it builds against clang-12 (there was a post-release change upstream I had to pull in). On the plus side, the giant LLVM-11 patches that USED to be applied are no longer necessary.

I'd submit a PR to, but I can't seem to log in right now — every attempt just gets me "Strange state: failure" so I guess the new accounts system is having some teething troubles.

Anyway, the branch diff against rawhide is here:

If you'd be up for taking a look at the branch, and hopefully applying it on both rawhide and f34, then submitting new builds of clazy against LLVM/clang 12, it'd be much appreciated. The versioned dependencies issue I asked about in my mailing list posting, I think can wait until the next round of changes, not worth holding up these fixes.

Let me know if you hit any issues or need anything else from me. If I can manage to get in to my account at src.fpo anytime soon I'll open a Real PR™ to go with the branch.

Comment 11 Jan Grulich 2021-05-04 08:47:26 UTC
I did create a PR from your changes and merged them. Thank you for your help. I will submit updates once the builds finish.

Comment 12 Fedora Update System 2021-05-04 09:47:19 UTC
FEDORA-2021-61b78213e0 has been submitted as an update to Fedora 34.

Comment 13 "FeRD" (Frank Dana) 2021-05-04 14:06:03 UTC
(In reply to Jan Grulich from comment #11)
> I did create a PR from your changes and merged them. Thank you for your
> help. I will submit updates once the builds finish.

Tested and working nicely in F34, thanks!

I would leave karma, but... I can't log in to bodhi, either, it seems.

500 Internal Server Error
Could not convert return value of the view callable function pyramid_fas_openid.view.verify_openid into a response object. The value returned was None. You may have forgotten to return a value from the view callable.

I guess I should start reporting these, since I assume not everyone is affected by this.

Comment 14 Fedora Update System 2021-05-05 01:50:01 UTC
FEDORA-2021-61b78213e0 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-61b78213e0`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 15 Cajus Pollmeier 2021-05-06 05:44:28 UTC
Tested it, and it works on F34 now. Thanks for the efforts! So I think this one can be closed sooner or later...

Comment 16 Fedora Update System 2021-05-12 05:43:02 UTC
FEDORA-2021-61b78213e0 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.