`compose container-encapsulate` crashes when `--max-layers` is less than 4
Closed this issue · 4 comments
Expected vs actual behavior
$ RUST_BACKTRACE=full rpm-ostree compose container-encapsulate --repo . --max-layers 1 fedora/x86_64/osbuild oci-archive:/home/obudai/images/container.tar
...
15: 0x5635290fd547 - ostree_ext::chunking::get_partitions_with_threshold::he757d2e7da6ccb8f
at /usr/src/debug/rpm-ostree-2023.5-1.fc38.x86_64/vendor/ostree-ext/src/chunking.rs:462:38
16: 0x5635290fd547 - ostree_ext::chunking::basic_packing::h6cb2cfb66ce07d6c
at /usr/src/debug/rpm-ostree-2023.5-1.fc38.x86_64/vendor/ostree-ext/src/chunking.rs:678:26
17: 0x5635290fd547 - ostree_ext::chunking::Chunking::process_mapping::hb0685b7f6461a024
at /usr/src/debug/rpm-ostree-2023.5-1.fc38.x86_64/vendor/ostree-ext/src/chunking.rs:321:23
18: 0x5635290f81f5 - ostree_ext::chunking::Chunking::from_mapping::h4ec621e2f37c6144
at /usr/src/debug/rpm-ostree-2023.5-1.fc38.x86_64/vendor/ostree-ext/src/chunking.rs:274:9
...
Steps to reproduce it
- Create an ostree repository
- Run:
rpm-ostree compose container-encapsulate --repo . --max-layers 1 fedora/x86_64/osbuild oci-archive:/home/obudai/images/container.tar
The issue goes away when I set --max-layers to 4 or higher.
I investigated a bit and there are two causes going on:
When --max-layers is set to 1 or 2, this line underflows (low_and_other_bin_limit is 3 but bin_size is 0). This causes Vec.drain to crash because limit_hs_bins contains a bogus value.
When --max-layers is set to 3, the code panics because it doesn't expect less than 4 bins.
Feel free to move this issue under ostree-ext, but the crash is visible in rpm-ostree, so I filled it here.
Definitely a bug, but is there a rationale for trying to use 1 or even 4?
Oh...is this about trying to be reproducible even if the upstream default changes?
osbuild was for some reason using --max-layers 1 in its test suite. I have no idea why. When we bumped the rpm-ostree version, the test started failing with rpm-ostree crashing. We solved the issue in the obvious way: We bumped --max-layers to something higher, but I can see that we can maybe remove the argument altogether.
Anyway, this bug is mostly about giving the user a reasonable error message, instead of just crashing. :)
PR in ostreedev/ostree-rs-ext#522
osbuild was for some reason using --max-layers 1 in its test suite. I have no idea why. ...
but I can see that we can maybe remove the argument altogether.
Right.