bruntib on master
[web] Get CodeChecker API versi… Merge pull request #3265 from c… (compare)
bruntib on master
[client] Fix storage of multipl… Merge pull request #3263 from c… (compare)
bruntib on master
[req] Upgrade lxml to 4.6.3 Merge pull request #3252 from c… (compare)
bruntib on master
[server] Cleanup unused data (c… Merge pull request #3243 from c… (compare)
:/usr/lib/python3/dist-packages
solved!
wait
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.
make
doesn't execute a full build just an incremental one on your changed filesmake
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.
mtime
of the source file is newer than that of the plist, this is emitted.
results
directory, always with a brand new analysis.
Thank you.
But if I want to do it as it was supposed to be done, will it work if I:
exactly that?
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 results
directory.
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:
export PATH=~/codechecker/build/CodeChecker/bin:$PATH
export PATH=/opt/rh/llvm-toolset-7/root/usr/bin:$PATH
REPO=~/repo
cd $REPO
git reset --hard
git pull --all
source ~/codechecker/venv/bin/activate
/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
fi
RESULTS=~/results
cd $REPO/mf
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:
make
actively rebuilding all the files that git pull
updated? 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 clean
(or 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 whatever
or unknown
as the name of the checker when storing.