Herodotus/How to try herodotos

One can install the herodotos tool (for p8) from the task mentioned in Herodotus#herodotos_in_p8: task 257760. (task 243195 has still an unmet dependency on gumtree, 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 hasher 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 study.hc 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 resolv.conf, one could bind the one from the host system with mount --rbind and mount --make-rslave, and mount -o remount,ro for extra safety additionally to hasher's UID switching. One could even try to configure this in /etc/hasher-priv/fstab if hasher-priv 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 (coccinelle) to each version of the sources (linux). The results are saved at /usr/src/HERODOTOS/ (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 *.orig.org files.

/usr/src/HERODOTOS/ 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 gear --hasher | hsh-rebuild again (after editing the Git repo with the Makefiles, configs etc). (TODO: Unfortunately, the automatically filled faults/.projects_study.hc file is not relocatable in a similar manner.)

• The next step (correlation of the warnings between versions by herodotos) 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 *.correl.org files with undecided possible correlations (marked as TODO);
• the *.new.org files with merged warnings from all versions. It is to be decided whether each of them (marked as TODO initially) is a real error or a false warning.

(In this example, I made herodotos use the --diff gnudiff option, because the default better --diff hybrid requires gumtree 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 faults/study.hc.base) and see how the warnings concerning the new version are merged with the marks for the old versions. Let's explore this.