gix cat: Encountered unsupported command code: 0

[ElvishJerricco]

Current behavior 😯

I encountered this after updating jj, but I bisected it to jj's update from gix 0.73.0 to 0.74.1, and bisected further to #2155

In a large repo I have, reading a certain object always fails.

$ gix cat 70b81af0814b0620db4af251b3f0e9530457104b
Error: An error occurred while obtaining an object from the packed object store

Caused by:
    Encountered unsupported command code: 0

Stack backtrace:
   0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
   1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
   2: gitoxide_core::repository::cat::display_object
   3: gitoxide_core::repository::cat::function::cat
   4: gitoxide::plumbing::main::main::{{closure}}
   5: gitoxide::shared::pretty::prepare_and_run
   6: gitoxide::plumbing::main::main
   7: gix::main
   8: core::ops::function::FnOnce::call_once
   9: std::sys::backtrace::__rust_begin_short_backtrace
  10: std::rt::lang_start::{{closure}}
  11: std::rt::lang_start_internal
  12: std::rt::lang_start
  13: main
  14: __libc_start_call_main
  15: __libc_start_main_alias_1
  16: _start

Expected behavior 🤔

The object should be readable, as it is with gix 0.73.0.

Git behavior

git cat-file -p 70b81af0814b0620db4af251b3f0e9530457104b in the same repo outputs the contents of a file in the repo.

Steps to reproduce 🕹

Unfortunately, I can only narrow this down to a 5.1GiB pack file, and I don't know how this problem was created. It seems like the pack file is valid, given that both git and earlier versions of gix read it fine. Copying the .pack file to a new repo and regenerating the .idx and .rev with git-index-pack preserves the problem, so the problem is in the .pack. Is there a way I can narrow down the pack file to just the problematic object?

[Byron]

Thanks for reporting and the initial investigation, and sorry for the hassle.

I understand this issue isn't present before #2155 was merged, and that it's unrelated to the pack index which was also regenerated. Thus, let me CC @folkertdev.

Besides that, I am pretty sure this is at least related to #2044, which was left open as well, with this comment being quite indicative of what seems to happen.

So it really seems to be something about zlib-rs and/or how these pack entries have been created. It could also be related to how gitoxide handles its buffers, but from all I could tell it just creates buffers of the required size and tells it to inflate everything into it in one go.