bruntib on master
[analyzer] Fix parsing clangsa … Merge pull request #3206 from c… (compare)
bruntib on master
[analyze] Fix duplication warni… Merge pull request #3213 from c… (compare)
4.18.0-193.19.1.el8_2.x86_64. It gives these errors.
[INFO 2020-12-21 10:54] - Starting static analysis ... [ERROR 2020-12-21 10:54] - Analyzing m1.c with clangsa failed! [ERROR 2020-12-21 10:54] - [ERROR 2020-12-21 10:54] - clang-10: error: unknown argument: '-mskip-rax-setup' clang-10: warning: optimization flag '-falign-jumps=1' is not supported [-Wignored-optimization-argument] clang-10: warning: optimization flag '-falign-loops=1' is not supported [-Wignored-optimization-argument] clang-10: warning: optimization flag '-fno-inline-functions-called-once' is not supported [-Wignored-optimization-argument] clang-10: warning: optimization flag '-fmerge-constants' is not supported [-Wignored-optimization-argument] clang-10: error: unsupported option '-mrecord-mcount' for target 'x86_64-redhat-linux'
Something weird is happing:
[WARNING 2020-12-23 00:47] - /usr/home/sa/repo/[...]template.c did change since the last analysis.
Please analyze your project again to update the reports!
How can this be resolved?
This is especially strange as it is cloned to a local ext4 filesystem with no other users or processes at all that can touch those files.
makedoesn't execute a full build just an incremental one on your changed files
The error you're getting is
store checking your actual files against what the
analyze command output as the state of the files. This is done because
store packages the necessary source files at the moment of upload but the results of
analyze can be older, so there could be the off-chance that you're uploading reports that point to locations in the source code that aren't there anymore in your source files. It's a safeguard.
I think it works based simply on timestamp.
mtimeof the source file is newer than that of the plist, this is emitted.
resultsdirectory, always with a brand new analysis.
But if I want to do it as it was supposed to be done, will it work if I:
So first run:
The workflow you described:
clone -> build -> check -> store -> pull -> build new version -> check the changed files -> store all results (incl. new ones and old ones still in results)
SHOULD work. I'm not sure why you get the timestamp issue. This workflow will work as long as you retain your
There is another workflow, which runs the analysis from scratch and uploads the full result set all the time:
clone -> build -> check -> store -> rm -rf results -> make clean -> pull -> make (all!) -> check -> store
That should work too. The server will not lose the results, the only thing you have to be careful about is to not have:
clone -> build -> check -> store -> rm -rf results -> pull -> make (the changed files) -> check (the changed files only!) -> store (a smaller result set)
because this one will switch all the reports from all the files that were not built after the subsequent pulls to Resolved (because from the server's perspective, the bugs disappered from the upload)
Weird. Something is still going wrong.
I do exactly this:
git reset --hard
git pull --all
/usr/sbin/ss -tnl | grep -q 'LISTEN.*:8001'
if [ $? -ne 0 ] ; then
echo Starting CodeChecker server
nohup CodeChecker server --host 0.0.0.0 &
# hopefully this is long enough. this should only be invoked # on the first run after a system boot. if it is not reliable; # replace it then by a while loop which invokes the 'ss' # command above sleep 5
CodeChecker check -b make -o $RESULTS
CodeChecker store $RESULTS -n mf
Yet I get (in the second run):
[WARNING 2020-12-23 16:14] - The following source file contents changed since the latest analysis:
makeactively rebuilding all the files that
git pullupdated? It seems the issue is there somewhere... there are files that get updated, but not re-analysed, and thus it breaks. Does it work if you always do a full new analysis (with removing
~/results, and also
make distclean) and then doing a full build & full analysis)?
[WARNING 2020-12-23 16:14] - Check name wasn't found in the plist file '/usr/home/sa/results/parser.c_clangsa_83ff4b537b2be004d37c504baf2319c1.plist'.
This is worrying. For some reason, the output of the Clang Static Analyzer generated a bogus plist. But this is just a warning, I think if the plist is too old (in terms of format), it'll just go with
unknown as the name of the checker when storing.