Control: severity -1 important Hi there,
On Saturday, June 01 2019, Steve McIntyre wrote:
> On Wed, May 29, 2019 at 04:30:05PM +0200, Lucas Nussbaum wrote:
>>Hi,
>>
>>During a rebuild of all packages in buster (in a buster chroot, not a
>>sid chroot), your package failed to build on amd64.
>
> Hmmm, that's odd. I've just built the current package in fresh amd64
> and i386 chroots here, with no errors.
I can also confirm building strace on a fresh sid chroot without errors.
> Checking your log, the /dev/kvm error is not fatal and some tests are
> skipped without KVM access.
Also confirming this.
> The actual failures that you're seeing are from 4 stat functions,
> reported several times due to the build setup:
>
> $ grep ^FAIL: strace_4.26-0.2_testing.log | less
> FAIL: lstat.gen.test
> FAIL: stat.gen.test
> FAIL: lstat.gen.test
> FAIL: trace_lstat.gen.test
> FAIL: stat.gen.test
> FAIL: trace_stat.gen.test
> FAIL: trace_lstat.gen.test
> FAIL: trace_stat.gen.test
> FAIL: lstat.gen
> FAIL: stat.gen
> FAIL: trace_lstat.gen
> FAIL: trace_stat.gen
> FAIL: lstat.gen
> FAIL: stat.gen
> FAIL: trace_lstat.gen
> FAIL: trace_stat.gen
>
> so I've updated the bug title. Checking the log for more details, I'm
> just seeing what *looks* like whitespace differences in the test
> output. But I don't see it here on my system, which is surprising. Is
> there anything at all special about your test setup that I should ba
> aware of? I'm pondering if there's maybe a locale setup difference or
> something, but that's just a guess OTTOMH...!
Yeah, I agree with Steve here; these failures seem strange, but they are
the apparent result of whitespace differences, and not real failures.
For example:
-lstat("/dev/full", 0xf7544fc0) = -1 EOVERFLOW (Value too large for defined
data type)
+lstat("/dev/full", 0xf7544fc0) = -1 EOVERFLOW (Value too large for defined
data type)
I spent some time looking into how strace prints these lines, and found
that there is a specific function responsible for calculating the amount
of whitespace that should go between the close parenthesis and the equal
sign (on strace.c):
void
tabto(void)
{
if (current_tcp->curcol < acolumn)
tprints(acolumn_spaces + current_tcp->curcol);
}
Here, "acolumn" is 40 (this value actually comes from a define in
defs.h, "DEFAULT_ACOLUMN"), and "tprints" actually calls
"fputs_unlocked", which is thread-unsafe according to its manpage. Not
that it matters much, since strace is single-threaded, but these are the
data points I gathered so far.
These functions don't seem to be affected by locale. I also noticed
that the test is actually comparing the output of "./lstat", which uses
a static way to generate the syscall information lines (i.e., it doesn't
have any mechanism for dynamically generating whitespaces according to
the number of columns printed -- take a look at tests/{xstatx,lstatx}.c
for more info), against the output generated by the compiled strace
binary, which, as stated above, is much more dynamic when printing
whitespaces. It seems to me that the testcase(s) should be adjusted to
account for possible differences in whitespace.
Having said all that, I believe this bug's severity should be reduced
from "serious" to (at most) "important", at least until Lucas can
provide more information about it. I've taken the liberty to do that;
feel free to bump it back to "serious" if needed, of course.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
signature.asc
Description: PGP signature
