1. Documentation
  2. Advanced Techniques

Advanced debugging

How to find interesting information outside of the user interface

These tips apply to both local installations and server installations, unless specified otherwise.

Docker containers

CI Fuzz usually builds, instrument and runs the software under test in Docker containers. Examining container logs can provide information depending on the application and type of fuzz tests. For Web Applications running in JVMs, you can check whether your application is starting and running correctly, what methods are instrumented and what http requests is the fuzz target sending to it (although for each logged request, a number of following ones is not logged to save space and performance). For C/C++ applications, you can spot problems with compilation or examine the output of your application/library.

When your fuzz test is running, use "docker ps" in your terminal to list containers:

$docker ps
140d5da059bb maven "bash -eux -c 'expor…" 3 seconds ago Up 1 second watchcov-WebGoat-wwqapcbi
b96d1d35996d maven "bash -eux -c 'expor…" 5 seconds ago Up 2 seconds fuzz-WebGoat-lwtgjawo
9424d1c22539 mongo "docker-entrypoint.s…" About a minute ago Up About a minute>27017/tcp ci-mongodb

Pick the container with name starting with fuzz-, followed by the name of your project. If you have two such containers, pick the second one. Then run docker logs,  followed by this container name. Example:

docker logs fuzz-WebGoat-lwtgjawo

Now you can examine your build and fuzzing thoroughly.

If you have issues at the project creation stage, you can also examine the logs of build containers. These have the word "build" in their name.

ci-daemon logs

When starting ci-daemon, you can increase log verbosity and see logs on standard error output by providing command line arguments:

$ ci-daemon -v2 --alsologtostderr

On a server, this is enabled by default. You can find the logs in systemd journal:

$ journalctl -u ci-server

However, when looking for messages from the software under test, it is recommended to look in docker logs instead, as they are more complete in that regard than ci-daemon logs.