Coverity: bug when navigating to source files (QB 5.1.15) #2774

Jonathan · 1 decade ago

When attempting to look at a file listed in the Coverity report QuickBuild goes to the wrong SVN URL e.g.:

The file main.cpp exists at the following SVN URL:

https://my.svn.repo/svn/projects/my_project/trunk/src/main.cpp

I check out the trunk folder to the following path and perfom a Coverity build:

f:\qb\my_project

Now when I navigate to the file via the Coverity report I receive an error within QuickBuild stating that the following file cannot be found.

https://my.svn.repo/svn/projects/my_project/trunk/qb/my_project/src/main.cpp

QuickBuild does not appear to be stripping the workspace folder from the path when constructing the SVN URL.

replies 13
views 4758
stars 0

steveluo ADMIN · 1 decade ago

Hi Jonathan,

Please tell me what is your file element looks like in the original JSON file, below is an example in my JSON file:


    "cid" : 27253,
    "mergeKey" : "c2f0355d1708cd7eef302a261ce88371",
    "occurrences" : [ {
      "checker" : "FB.DM_DEFAULT_ENCODING",
      "file" : "/src/megamek/client/Client.java",
      "function" : "megamek.client.Client.saveEntityStatus(java.lang.String)",
      "extra" : "",
      "subcategory" : "none",
      "mainEventLineNumber" : 1015,
      "mainEventDescription" : "Found reliance on default encoding: new java.io.FileWriter(String)"
    } ],

Jonathan · 1 decade ago

Here is the file element from my file:


"file" : "/qb/mne-properties/src/wmi/wbemquery.cpp",

steveluo ADMIN · 1 decade ago

Is it possible to let Coverity use a full path for 'file' element? Here in your example, I notice that the drive letter 'f:' is missed.
QuickBuild cannot understand this path as this path can be an absolute path on Linux or Unix alike system, or can be on any drive on Windows system.

steveluo ADMIN · 1 decade ago

By the way, in my Coverity JSON file, it seems they are using a relative path, so you can also check if the path can use a relative path to your workspace directory.

Jonathan · 1 decade ago

Unfortunately it is not possible to modify the file element.

Coverity identifies files by their paths <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />, this is how it maps files to components and keeps track of when defects have been fixed.

If we simply stored the working copy of each file i.e. /src/wmi/wbemquery.cpp then Coverity would not be able to map any defects found in that file to the relevant component.

If however we stored the full path, i.e. f:/qb/mne-properties/src/wmi/wbemquery.cpp then we would have a similar problem when we ran Coverity on a build agent that was checking out to a differnt folder, i.e. c:/qb/mne-properties... or c:/quickbuild/workspace/mne-properties/...

Could we perhaps "fix-up" the JSON file? would QuickBuild be able to display the files correctly if we modified the file element within the JSON file to contain absolute paths?

steveluo ADMIN · 1 decade ago

Just notice that in the JSON file, there is a section like below:


"analysisInfo" : {
    "reportTimestamp" : "2013-07-09T18:44:19.302Z",
    "command" : "C:\Coverity\analysis\bin\cov-analyze.exe --java --quality --jobs=auto --strip-path=C:\rich\megamek-0.35.30-source --enable-fb --disable-webapp-security --config=C:\Coverity\analysis\config\coverity_config.xml --all --dir=C:\rich\analyzed\megamek",
    "user" : "admin"
  },

I'd like to know is --dir here is the source directory where you run coverity? I have to ask you this question and others, because we (PMEase) are not coverity customer and I can't get any Coverity manual.

Jonathan · 1 decade ago

Our analysis section is as below:


  "analysisInfo" : {
    "reportTimestamp" : "2014-04-15T18:11:11.659Z",
    "command" : "cov-analyze.exe --all --aggressiveness-level medium --dir F:\QB\MNE-Properties\build\coverity/Properties",
    "user" : "admin"
  },

The --dir parameter merely indicates the location for the analysis output.

There is a deeper problem here. Below are two additional file elements from the same coverity analysis file:
"file" : "/program files (x86)/microsoft visual studio 12.0/vc/include/wchar.h"
"file" : "/program files (x86)/windows kits/8.1/include/shared/stralign.h",

As you can see our build is pulling in files from other parts of the installed tool chain. In our system these will likely be installed to drive C: whilst source code is likely to be checked out to drive F:. As such there is unlikely to be a single path that you can prepend to the file elements in the JSON file to absolutely identify all files.

steveluo ADMIN · 1 decade ago

The problem we are facing is that how can we construct the full/absolute path for coverity file. Is it possible for you to ask Coverity support?

If we can't get the full/absolute path, we may have to remove the view source code link from Coverity plugin.

#10

vanderhu · 1 decade ago

Are you making use of --strip-path, because what manual says is:

--strip-path <path>, -s <path>
Strips the prefix of a file name path in error messages and references to your source files. If you specify
the --strip-path option multiple times, you strip all of the prefixes from the file names, in the
order in which you specify the --strip-path argument values.

#11

steveluo ADMIN · 1 decade ago

Hi vanderhu,

Thank you for mentioning this. Would you please help to confirm whether you can view source code or not from Coverity report?

#12

vanderhu · 1 decade ago

If I use --strip-path like ${configuration.getWorkspaceDir()}/code when our repository is being checked out in code folder, I am not able to browse to the files. Currently testing without strip-path option and afterwards with ${configuration.getWorkspaceDir()} only. Will update accordingly the post here.

By making not use of --strip-path it is working as expected and I can safely navigate to the source files.

#13

Jonathan · 1 decade ago

The trouble with --strip-path is that you need to know where all your source code lives.

Argueably you always know where your working copy is, however what about other parts of the toolchain that you might install e.g. Our builds often pull in files from VisualStudio, WIndows Kits, Boost etc. Although these are likely to be installed on drive C: somewhere there is no guarantee.

I will see if stripping the workspace and some other common folders / drives is a good enough solution.

#14

steveluo ADMIN · 1 decade ago

Hi,

@vanderhu, thank you very much for sharing this to me:

By making not use of --strip-path it is working as expected and I can safely navigate to the source files.

@Jonathan
The sources from Visual Studio, Windows Kit and boost are codes from third party, do you really very care about it? Let me know what is your result after stripping the workspace and others.