Herodotus/How to try herodotos

One can install the herodotos tool (for p8) from the task mentioned in Herodotus: task 257760. (task 243195 has still an unmet dependency on, which is optional.)

If you want to try herodotos, try to reproduce the authors' work https://github.com/coccinelle/faults-in-linux. (It is more recent; the older work http://coccinelle.lip6.fr/papers/aosd10.pdf with their data and configuration is not suitable for the current herodotos 0.8+ version.)

I've adapted their herodotos config files and made it a Gear repo: http://git.altlinux.org/people/imz/public/faults-in-Linux.git, so that one can easily pass it to and do the processing in an isolated, easily reproducible hasher environment.


 * First, prepare: clone my repo and and set up the sources for APT:

$ git clone --depth=20 git://git.altlinux.org/people/imz/public/faults-in-Linux.git $ cd faults-in-Linux $ apt-repo --hsh-apt-config=/home/imz/.hasher/p8/apt.conf add 257760


 * Here is what the APT sources config for the hasher should be like (and our current working dir):

$ apt-repo --hsh-apt-config=/home/imz/.hasher/p8/apt.conf rpm [updates] file:/ALT/p8 x86_64 classic rpm [updates] file:/ALT/p8 noarch classic rpm http://git.altlinux.org repo/257760/x86_64 task $ pwd /space/home/imz/wip/2018-10-herodotos-cppcheck/faults-in-Linux


 * Then, we execute the authors' processing rules (under the control of my .gear/faults-in-Linux.spec-file from the master branch; it automatically gets and checks out various revisions of the linux sources (so, you must have enough space to hold it):


 * Initialize the hasher chroot.

$ hsh --apt-config=/home/imz/.hasher/p8/apt.conf --without-stuff --ini


 * Prepare for networking in hasher. (The  herodotos config in this example refers to our kernel Git repository hosted on the network. And it'll have to resolve the host name.)

$ hsh-run --root -- sh -c 'cat >/etc/resolv.conf' </etc/resolv.conf $ export share_network=1


 * (Instead of statically copying, one could bind the one from the host system, i.e.,  to avoid symlinks, with  and , and  for extra safety additionally to hasher's UID switching. One could even try to configure this in  if  understood all these mount options.)


 * Optionally, test that resolving the host name works.

$ hsh-install telnet $ hsh-run -- telnet git.altlinux.org 80


 * Finally, run herodotos, which will download the sources (the Linux kernel in this example), unpack different revisions, cache them, and analyze.

$ gear --hasher -- hsh-rebuild 2>&1 | tee hsh.log.1


 * It stops after the step of applying the static analyzer to each version of the sources (linux). The results are saved at  (inside hasher). I've copied them and saved in commit ad458b0c2 in the EXPERI/imz2/apply-analyzer-results branch, so that you can look and get an idea what they look like:


 * the individual per-version files.

is used as the place to cache the analyzed sources and to save the (intermediate and final) results, so it won't be cleaned if you run again (after editing the Git repo with the Makefiles, configs etc). (TODO: Unfortunately, the automatically filled file is not relocatable in a similar manner.)


 * The next step (correlation of the warnings between versions by ) is to be run by us manually (because I wanted to have a possibility to first commit the results of the previous step):

hsh-shell --mount=/proc,/dev/pts cd /usr/src/RPM/BUILD/faults-in-Linux-20181023/faults/ make correl


 * or as a single command:

hsh-run --mount=/proc -- sh -c 'cd /usr/src/RPM/BUILD/faults-in-Linux-20181023/faults/ && make correl'


 * I saved the results in commit c3f5e56dd7e in the EXPERI/imz2/correl-gnudiff-results branch, so that you can look and get an idea what they look like:


 * some non-empty  files with undecided possible correlations (marked as );
 * the  files with merged warnings from all versions. It is to be decided whether each of them (marked as  initially) is a real error or a false warning.

(In this example, I made use the  option, because the default better  requires  and doesn't work correctly if it is absent.)

A follow-up scenario would be to first mark some warnings as checked and then add another version of the project into consideration (by editing the pattern in ) and see how the warnings concerning the new version are merged with the marks for the old versions. Let's explore this.