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
Description: OpenPGP digital signature
__ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.