CodeQL Actions: C++ analysis runtime error.

[asraa]

Hi there,

I ran into an issue setting up CodeQL scanning in Envoy (https://github.com/envoyproxy/envoy), which I enabled in a PR here envoyproxy/envoy#11590.

I was able to get a successful custom build for our C++ database, but ran into an error during the analysis step in the CodeQL process:

2020-06-15T17:37:58.5293036Z [command]/opt/hostedtoolcache/CodeQL/1.0.0/x64/codeql/codeql database finalize /home/runner/work/_temp/codeql_databases/cpp
2020-06-15T17:37:59.7699264Z Running TRAP import for CodeQL database at /home/runner/work/_temp/codeql_databases/cpp...
2020-06-15T18:09:29.0621568Z Oops! A fatal internal error occurred.
2020-06-15T18:09:29.0630894Z java.lang.RuntimeException: java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code
2020-06-15T18:09:29.0631049Z 	at com.semmle.util.exception.Exceptions.asUnchecked(Exceptions.java:103)

Here’s the logs and config for the run: https://github.com/asraa/envoy/runs/772810943?check_suite_focus=true
(Also relatedly, I get back an email report for the run, but why does it show up in my fork?)

Does anyone have any pointers or can tell me where to start looking? Thanks!

[robertbrignull]

We think it means the process ran out of disk space, and it's just a very confusing error message. I can see your project took 4 hours to build, so it's quite a large one, and thus it's possible you'll run into resource constraints.

The CodeQL team are going to make a change to improve the error message for this, but that's not going to fix your problem.

I think you want to try finding a way to get back some disk space. For this there are a few options:

• If it's acceptable then a good option would be just building less code. Perhaps there are bits you could avoid, or perhaps split it up into multiple workflows each building and analyzing a subset. This will speed up analysis because the parts will proceed in parallel.
• Clean the workspace before running the queries. So after building but before running the analyze action you could run git clean (maybe with -xdf) to clean up build artefacts. The necessary data about them has already been recorded so those files aren't needed anymore. You could even try deleting the entire repository as the source code isn't needed at that point. (Note this only works because you're analyzing C code. If it was python/javascript/etc then we need the code at that stage to scan it.)
• You note in your PR that you want to try self-hosted runners. That would let you give it more resources. Do note however that self-hosted runners for open-source projects are a bit difficult because you are letting people run arbitrary code on your hardware.

[asraa]

Thanks so much for the detailed reply! I see.
I'll try solution (2) first, but the 4 hour build is unappealing as it is. Splitting up or focusing our analysis on vulnerable parts of code as in (1) is probably the solution. We'll fallback on (3) after thinking about our current posture against this Our current CI checks also run on machines, but I can see that this script is a pretty open attack surface.

[robertbrignull]

Cleaning the workspace will get you back a little bit of space so let's just hope it's enough.

The warning about self-hosted runners is more than anyone can open a PR to change what your workflows do. At that point it doesn't matter what the workflow originally did.

[robertbrignull]

I'm closing this issue now as it seems everything is working again with the info above. If not please fees freeto re-open or comment.