7

UPDATE: See the solution in Caleb's answer

I am trying really hard to make Coverity work for my build, but so far with little success.

First the details:

I started by downloading a package from: https://scan.coverity.com/download/java/win64

Then I added the bin directory to my path, went to my project root and ran the following commands.

$ set PATH=%PATH%;C:\Users\dimit\sandbox\cov-analysis\bin
$ gradlew clean
$ cov-build --dir cov-int gradlew jar

The first 2 went as expected, the last - not so much:

Coverity Build Capture (32-bit) version 8.7.0 on Windows 10 Professional, 64-bit (build 14393)
Internal version numbers: b452b3f2c8 p-lodi-push-28091.612

The system cannot execute the specified program.
[WARNING] Build command gradlew.bat jar exited with code 1. Please verify that the build completed successfully.
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
 For more details, please look at:
    C:/Users/dimit/sandbox/nuggets/cov-int/build-log.txt

I have put the build log here: https://gist.github.com/ddimtirov/9daa0e9f1f0954453f01fcec42ae2198

The "Troubleshoot build failure" on the instructions page was pointing to a forum index page, which does not help at all: https://software-community-synopsys.force.com/s/#4838

Moving on, I thought that if I could only generate the data in some other way I could upload it to the scan service and bypass the problem. I found https://github.com/mjdetullio/gradle-coverity-plugin

The Gradle Coverity plugin emitted the data, but when I zipped it and uploaded to the scan service, it barfed the error email.

As last resort, I tried the TravisCI integration - after a few attempts, I got it to complete without an error, but it didn't seem to upload anything...

https://travis-ci.org/ddimtirov/nuggets/builds/196307253 https://scan.coverity.com/projects/ddimtirov-nuggets?tab=overview

I am close to giving up (BTW, not having docs available online doesn't help)

ddimitrov
  • 3,293
  • 3
  • 31
  • 46
  • Looking at the build log you posted, nothing happened when `gradlew.bat` was executed, and the console seems to say that whatever you tried to execute, "The system cannot execute the specified program" (that came from your build command, not Coverity. Have you tried running that command directly to see what happens? – Caleb Feb 03 '17 at 04:01
  • When I run `gradlew jar` without coverity it compiles and builds a JAR. Also, if you have a look at the linked TravisCI job, you will see that the same produces different output when run on the linux server. – ddimitrov Feb 03 '17 at 04:27

2 Answers2

5

Issue 1 - "The system cannot execute the specified program."

This issue arose because a Windows 32-bit kit was used to attempt to capture a Windows 64-bit build. The attempt to attach a 32-bit process to a 64-bit one causes failure to execute.

  • The solution here is to match the bitness of Coverity binaries with the bitness of your platform (use a Windows 64-bit kit).

Issue 2 - Failure to capture TravisCI build on Linux

This issue appears to be due to an incompatibility between Coverity's Java Capture and the ErrorProne plugin, as evidenced by messages such as this one in the build log:

WARNING: Failed load class file java/io/FileNotFoundException.class as a resource using the class loader net.ltgt.gradle.errorprone.ErrorProneCompiler$SelfFirstClassLoader@36358417
  • The solution here is to disable that plugin for the Coverity build.

Varia

  • When debugging the issue, the known issue of the Gradle daemon interfering with Coverity was discussed, but was ultimately not relevant to the issue.
  • The noted issues with the "prepend" command are user error; the prepend command is not a separate command to run, it's there for utility purposes.
Caleb
  • 1,143
  • 5
  • 13
  • Thanks for the tip, a bit more background on how Coverity extracts the information may reduce your support burden. Please fell free to point me to any resources I may have missed. I tried no-daemon on Windows 10 - still failing in the same opaque way - if I was able to see the cpommand stdout or error code would have been useful. I am not sure if my Travis CI setup is correct (in particular the add-on and my build script). Iwould appreciate if you could have a look at this job and the associated commit: https://travis-ci.org/ddimtirov/nuggets/jobs/199040064 – ddimitrov Feb 07 '17 at 00:25
  • I took a peek in the Travis log, and I see something suspicious: ":buildSrc:compileJava UP-TO-DATE" et. al, with a total build time of 1.59 seconds. Did anything actually build? – Caleb Feb 07 '17 at 01:54
  • The `:buildSrc:compileJava` does not build anything, `:compileJava` does. See line 394 in this build for comparison: https://travis-ci.org/ddimtirov/nuggets/jobs/198719233#L394 – ddimitrov Feb 07 '17 at 02:14
  • I noticed that env vars are `COVERITY_SCAN_BUILD_COMMAND="${COVERITY_SCAN_BUILD_COMMAND:-./gradlew --no-daemon jar}" COVERITY_SCAN_BUILD_COMMAND_PREPEND="${COVERITY_SCAN_BUILD_COMMAND_PREPEND:-./gradlew clean}"` -- in this case I can see the PREPEND command running, but I don't see the BUILD command... – ddimitrov Feb 07 '17 at 02:19
  • I suspect that's your problem then - you're not running your full build, so Coverity isn't seeing it. I believe the `COVERITY_SCAN_BUILD_COMMAND_PREPEND` is prepended to `COVERITY_SCAN_BUILD_COMMAND` and is presumably used to do something like set an env var. Can you combine both of these into a single build command? – Caleb Feb 07 '17 at 21:02
  • Not running Gradle in the prepend-command moves us forward (btw that seems to be rather arbitrary undocumented restriction). Now the build runs and creates a JAR file (evidence at line 424), but Coverity still doesn't pick up on it (see the Coverity build log from line 479 onwards). The Travis build I refer to is here: https://travis-ci.org/ddimtirov/nuggets/jobs/199474714#L424 – ddimitrov Feb 08 '17 at 03:07
  • Can you link the build log from that run? – Caleb Feb 08 '17 at 03:57
  • It is printed at the bottom of the travis log. Starting a line 479 (you need to click the little arrow in the left gutter to unfold) – ddimitrov Feb 08 '17 at 04:01
  • Thanks. It would seem this is the cause of the problem: "WARNING: Failed load class file java/io/FileNotFoundException.class as a resource using the class loader net.ltgt.gradle.errorprone.ErrorProneCompiler$SelfFirstClassLoader@36358417" Coverity's Java capture agent works by injecting a JAR file into the build, which allows it to see the compilation steps that are occurring. I suspect this JAR file has some dependencies that are somehow not being satisfied. If you can figure out why, your issue will probably be fixed - otherwise I think you'll need to engage directly with SCAN support. – Caleb Feb 09 '17 at 17:09
  • DID IT! So it turns out that Coverity bombs if the Google Errorprone plugin is enabled. It would be nice if that is solved, as it is a nice feature. Do you think I can contact support about that? (Last time I tried, I didn't receive response). – ddimitrov Feb 10 '17 at 05:13
  • Also, do you have any idea how to start investigating about the windows build? – ddimitrov Feb 10 '17 at 05:13
  • Coverity's support@coverity.com will reject SCAN customers requests (although I think they should at least accept bug reports). There is a SCAN admin who is very happy to engage with and help SCAN customers and actively advocates for bugfixes - so if you contact that channel, you should be well satisfied. I'll also make an unofficial report to the team responsible for this area of the product; I suspect they'll appreciate the heads up. – Caleb Feb 10 '17 at 18:57
  • As for investigating the Windows build, the story there is about the same. The first step is to find out what the difference is. Ensuring identical environments is step #1 - it's a common problem where people open up a cmd.exe terminal that doesn't have the same environment as their build and run into issues. Then it's a matter of investigating the build log for clues and chasing them down. I'm not expert on the build capture side of things, so I'm somewhat limited in my ability to help there. – Caleb Feb 10 '17 at 18:59
  • My previous email was to scan-admin. I have forwarded the finding form this conversation again, but I would appreciate if you would just check that they are received. As my email may be caught in some filters, I've included the word "Limburger" in the email body, so it would be easier to search for. – ddimitrov Feb 11 '17 at 01:30
  • Confirmed that the Windows issue was caused by the 32 vs 64 bit version. – ddimitrov Feb 17 '17 at 03:24
1

A few things to note, because reading our documentation is crucial to using our tool successfully:

  1. Kotlin is not supported.
  2. Using the appropriate binaries for your platform is required (so using win32 binaries on a 64 bit platform will generally not work).
Brad Larson
  • 170,088
  • 45
  • 397
  • 571
SCAN Admin
  • 11
  • 1