On 05/18/2014 08:59 AM, Michael Tautschnig wrote: > Hi Tony, > > [...] >> Looking at the org.jvnet.hudson.Top class used by this test, the parsing >> is potentially brittle, so I suspect the issue is related to differences >> in the output of top in your environment. >> >> If you could please install procps in your chroot build environment and >> provide the output for the bug report, that would be helpful. That is: >> >> top -b -n1 > ./top.txt >> > > Please find the requested output attached to this email.
Thank you Michael.
That explains the problem. It looks like your system has 256GB on it,
but the default for top is to display in KB, so the '+' (which indicates
truncation) is tripping up the class that parses the output.
> KiB Mem: 26465643+total, 11191324 used, 25346510+free, 1385252 buffers
> KiB Swap: 14483046+total, 40240 used, 14479022+free. 7171196 cached Mem
^
Currently, this test and class in general will fail on any system with
more 96GB on it. And it seems wrong to patch the code to just accept
the truncated value. I don't see a way to set the scaling factor from
the command-line invocation (and it introduces decimal points to the
output anyway). I don't have access to a system with that much memory
on it (none of the public porterboxes appear to have more than 32GB),
and am wondering if the -w (width) option will help.
If you are willing, the output of the following on your build system
would helpful for creating a patch for large memory systems:
top -n1 -b -w256
Thanks again,
tony
signature.asc
Description: OpenPGP digital signature
