https://bugzilla.redhat.com/show_bug.cgi?id=2281965
--- Comment #5 from Ben Beasley <code(a)musicinmybrain.net> ---
(In reply to Fabio Valentini from comment #4)
I took a quick look at the test failures.
On i686, it looks like it's failing to allocate 1.6 GB in the doctest that
adds the current directory (".") into a tar archive.
This likely includes the "target" directory, so any compiled artifacts
generated during %cargo_build and %cargo_test.
This is likely working *most of the time*, but it's maybe not a good idea in
general.
see
https://github.com/vorot93/tokio-tar/blob/master/src/builder.rs#L400
This is a logical explanation, although something still isn’t *entirely* adding
up—when I tested this in an fedora-rawhide-i386 mock chroot, the target
directory was only 303M, so this allocation still seems bizarrely large.
Would be nice if upstream had a bug tracker.
Still, an arch-dependent or even unconditional test skip is probably the way to
go here regardless of what is going on. The only reason to build i686 is to
avoid having to propagate ExcludeArch, not to actually *use* it.
On s390x, I can't really tell what's going wrong. The error message isn't
that helpful because the test just "assert!(entries.next().await.is_none()"
instead of using "assert_eq!(entries.next().await, None)", which would print
the value that is "not none" in the error message instead of just saying
"I
wanted a true, but I got a false! FAIL"). Is the failure persistent? It
might just have been a fluke.
see
https://github.com/vorot93/tokio-tar/blob/master/tests/all.rs#L1103
Good question. I just kicked off five scratch builds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=118005832
https://koji.fedoraproject.org/koji/taskinfo?taskID=118005833
https://koji.fedoraproject.org/koji/taskinfo?taskID=118005834
https://koji.fedoraproject.org/koji/taskinfo?taskID=118005842
https://koji.fedoraproject.org/koji/taskinfo?taskID=118005845
The test didn’t fail on s390x again, but it did fail twice on aarch64 with
similar output:
failures:
---- insert_local_file_different_name stdout ----
thread 'insert_local_file_different_name' panicked at tests/all.rs:1103:5:
assertion failed: entries.next().await.is_none()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
insert_local_file_different_name
test result: FAILED. 50 passed; 1 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 1.05s
error: test failed, to rerun pass `--test all`
Running
`/builddir/build/BUILD/tokio-tar-0.3.1/target/rpm/deps/entry-5ef2d6d85a16be6a`
…and one of those times, two other tests failed as well:
failures:
---- insert_local_file_different_name stdout ----
thread 'insert_local_file_different_name' panicked at tests/all.rs:1103:5:
assertion failed: entries.next().await.is_none()
---- large_filename stdout ----
thread 'large_filename' panicked at tests/all.rs:195:5:
assertion `left == right` failed
left: 0
right: 4
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- writing_files stdout ----
thread 'writing_files' panicked at tests/all.rs:160:5:
assertion `left == right` failed
left: 0
right: 4
failures:
insert_local_file_different_name
large_filename
writing_files
test result: FAILED. 48 passed; 3 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 1.05s
As I just wrote in
https://github.com/astral-sh/uv/issues/3423#issuecomment-2123668288,
It looks like the `insert_local_file_different_name` is flaky, roughly less
than 20% of the time, on `s390x`, but it also occurs (more frequently) on
`aarch64`. I have also observed flaky failures in other tests on `aarch64` – at
least `large_filename` and `writing_files`, and my notes indicate that I saw
`path_separators` panic in a previous attempt.
I think a reasonable conclusion here is that `tokio-tar` has significant race
conditions, at least on some architectures, and should have engaged in much
more fearful concurrency.
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2281965
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...