Control: reassign -1 litl-tools Hello,
Mattia Rizzolo, on Thu 12 Nov 2015 08:28:59 +0000, wrote: > it (can?) generate very huge files that fills > the entire file system (and we have a 200GB file system). Urlgllg, to say the least... > mattia@profitbricks-build5-amd64 /srv/workspace/pbuilder % sudo lsof > 2>/dev/null | grep deleted | grep eztrace > sh 64627 1111 1w REG 0,34 205408100352 > 2360061294 > /srv/workspace/pbuilder/3308/build/eztrace-1.1/build-mpich/test/automake/testlog0.txt > (deleted) > litl_prin 64628 1111 1w REG 0,34 205408100352 > 2360061294 > /srv/workspace/pbuilder/3308/build/eztrace-1.1/build-mpich/test/automake/testlog0.txt > (deleted) > litl_prin 64628 1111 3r REG 0,34 570 > 2360034123 /srv/workspace/pbuilder/3308/tmp/pbuilder1_eztrace_log_rank_1 > (deleted) Ok, so it's actually litl_print from litl-tools which went crazy, thus reassigning. To explain a bit: litl_print read a trace file (pbuilder1_eztrace_log_rank_1, 570 bytes long), and writes a dump of the trace (testlog.0.txt). The dump (ascii format) is supposed to be bigger than the trace (binary format), but not *that* bigger :) So I guess somehow the read loop got it wrong while reading the trace. I couldn't reproduce the issue, even with parallel=64 on a 24-core system (the testsuite is not supposed to run in parallel anyway), but the code is quite simple, so perhaps I can just proofread it and submit patches for tests. One thing that struck me at first look should be fixed by the attached patch, could you give it a try? > Furthermore the tests are not considered in the build process, so they > are actually completely useless, so I even wonder what's the whole point > on running them... To keep a history of their failure/success. Some are known to fail in a pbuilder environment, they are still to be investigated. Samuel