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

Reply via email to