by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 24 16:47
    bulwahn commented #2938
  • Sep 24 16:46
    bulwahn commented #2950
  • Sep 24 15:01
    csordasmarton milestoned #2952
  • Sep 24 15:01
    csordasmarton labeled #2952
  • Sep 24 15:01
    csordasmarton labeled #2952
  • Sep 24 15:01
    csordasmarton opened #2952
  • Sep 24 13:28
    bruntib commented #2940
  • Sep 24 13:14

    bruntib on master

    [gui] Show number of filtered i… Merge pull request #2942 from c… (compare)

  • Sep 24 13:14
    bruntib closed #2942
  • Sep 24 13:14
    bruntib closed #2862
  • Sep 24 10:34

    csordasmarton on master

    [style] Fix some pycodestyle is… Merge pull request #2951 from b… (compare)

  • Sep 24 10:34
    csordasmarton closed #2951
  • Sep 24 09:45
    csordasmarton labeled #2950
  • Sep 24 09:45
    csordasmarton labeled #2950
  • Sep 24 09:45
    csordasmarton milestoned #2950
  • Sep 24 09:44
    gyorb commented #2950
  • Sep 24 09:36
    bruntib review_requested #2951
  • Sep 24 09:36
    bruntib review_requested #2951
  • Sep 24 09:36
    bruntib labeled #2951
  • Sep 24 09:36
    bruntib opened #2951
Marc-Andre Laperle
@MarkZ3
@gyorb I can try this, but I am using absolute path though.
Marc-Andre Laperle
@MarkZ3
BTW, the updated doc is nice!
Gyorgy Orban
@gyorb
@MarkZ3 which CodeChecker version did you try? The latest release v6.6 or the master branch?
Marc-Andre Laperle
@MarkZ3
hmmm, maybe it was 6.5.1
Marc-Andre Laperle
@MarkZ3
I get the same behavior with 6.6.0. But I'll try to make a small example to make sense of it and open an issue if necessary
Gyorgy Orban
@gyorb
thanks that would be great
Marc-Andre Laperle
@MarkZ3
@gyorb Actually, I think it was working but I misread the results, in the CodeChecker UI. The bugs in the skiped files are there but "resolved". It there any way to remove permanently all revolved bugs? There are not useful to me since they appeared before I set my analysis to skip them.
Gyorgy Orban
@gyorb
@MarkZ3 sorry for the late reply, in our upcoming release v6.8 it will be supported to remove results
Marc-Andre Laperle
@MarkZ3
@gyorb Thank you! I'm not sure I'll be using CodeChecker again soon but this should be useful!
René Paris
@reneparis
Hey guys! First of all great tool!
I've been playing around with the server all day and really got issues with incompatible thrift versions (0.11.0 debian buster).
I've updated version of thrift in the requirements from 0.9.1 to 0.11.0 and everything seems to generate nicely
server is coming up, storing now works, but firefox says: TypeError: Thrift.copyList is not a function (report_server_types.js:2068:27)
Any ideas on that?
René Paris
@reneparis
sorry - just found bug issue #1827 - nevermind
Gyorgy Orban
@gyorb
hi, yes, you need to update thrift.js to the newer version as discussed in the issue
let us know if you have any other questions
René Paris
@reneparis
I've responded directly in the issue to keep the information together ;)
Gyorgy Orban
@gyorb
great, thanks!
matthijs
@matthijs
When compiling my project with clang++ on linux I always use the flag -stdlib=libc++ (selecting another std library). And a different std as well (-std=c++17). But when I check the static analyzer command I see that the libstdc++ headers are added to the compile line instead of the ones from libc++.
I already tried to set the commandline option --saargs to a file containing: -stdlib=libc++ and -std=c++17 but that didn't change anything.
What is the correct way to select a standard library?
Gyorgy Orban
@gyorb
hi, the -std=c++17 should not cause a problem, my first idea is that during the detection of the implicit includes for the compiler in https://github.com/Ericsson/codechecker/blob/046409b65457a5a0cab239f9d6d1df4906122d73/analyzer/codechecker_analyzer/buildlog/log_parser.py#L315 we do not forward the -stdlib=libc++ flag if it is in the compile command and without it the libstdc++ headers are collected, the saargs arguments are only forwarded for the actual analysis call
could you send an example of the compile command which is logged and the analysis command created from it?
I used the following CodeChecker command:
CodeChecker check --logfile compile_commands.json --output ../results --verbose debug --capture-analysis-output
Gyorgy Orban
@gyorb
I've made a PR Ericsson/codechecker#2294 with some changes, where the -stdlib= is kept where the implicit include paths are detected, with that it should return the right include paths, could you check it?
matthijs
@matthijs
Sure, I'll check it in a few hours.
matthijs
@matthijs
After applying the patch I got a python error: https://gist.github.com/matthijs/dd74249b585e00abdef17f7ecfd3af11
hm that also happens on current master without this patch
matthijs
@matthijs
Ok, I downloaded the release 6.10.0 and applied the patch, same results. I still do not see the headers from libc++
matthijs
@matthijs
Gyorgy Orban
@gyorb
I've updated the PR, we filtered out the -stdlib= flag earlier that is why it was not forwarded to the part where we get the implicit include paths, could you try it again?
matthijs
@matthijs
Yes, now I got the headers for libc++.
But unfortunately that gives another problem with the order of the includes, the order is now:
-isystem /usr/lib/llvm-7/lib/clang/7.0.1/include -isystem /usr/lib/llvm-7/include/c++/v1 -isystem /usr/local/include -isystem /usr/include/x86_64-linux-gnu -isystem /usr/include
but the include /usr/lib/llvm-7/include/c++/v1 should come before /usr/lib/llvm-7/lib/clang/7.0.1/include
it is now causing a failure described in a debian bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855222
matthijs
@matthijs
for your info, I tested the analyze command with the include order set correctly and then everything works correctly.
Gyorgy Orban
@gyorb
what is the include path order printed by this command? clang -x c++ -stdlib=libc++ -v -E - to see what was the original order
you use the clang from a standard debian package or you built it from source?
do you use the same clang for compilation and analysis?
matthijs
@matthijs
search order:
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/llvm-7/bin/../include/c++/v1
 /usr/include/clang/7.0.1/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
yes, this is the debian package from buster and I use the same clang for compilation and analysis.
Gyorgy Orban
@gyorb
we are reviewing how the compiler include paths are handled, there are multiple PR which introduce some changes Ericsson/codechecker#2297, Ericsson/codechecker#2294, Ericsson/codechecker#2272 (there is still some discussion how this change will affect the include paths and what should be the default behaviour) probably all of them will be needed to fix the problem
matthijs
@matthijs
Thanks, I already saw several comments on the PR's. I'll apply them and check if it fixes my problems.
Is there already an ETA for the next release?
Gyorgy Orban
@gyorb
we are planning the next release at the end of September or at the beginning of October
matthijs
@matthijs
I can confirm that by applying the 3 PR's that my code is analyzed without problems. Hopefully those can be merged before the next release. Thank you!
Gyorgy Orban
@gyorb
great news, thanks for testing it!