bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

[Philip McGrath <philip@philipmcgrath.com>]

Hi Mark and everyone,

On 4/14/21 1:54 AM, Mark H Weaver wrote:
> Recall that the grafting code performs a set of substitutions, replacing
> store item names (i.e. file names in /gnu/store) with replacement store
> items of the same length, with rules like:
> "fx3979c88s9yxdbchyf36qryawgzpwb5-libx11-1.6.10" =>
> "rwkqxykm91a75w9afhb41saj0dmf30hw-libx11-1.6.12".
> 
> The grafting code currently only checks the first 33 bytes, consisting
> of the nix-base32 hash and the "-".  It *assumes* that the remainder of
> the associated store item name immediately follows, and blindly writes
> the replacement string over whatever is there.
> 
> In this case, I suspect that within a *.zo file, a Guix store item name
> was split into pieces, with the hash and "-" together in one piece but
> split somewhere between the "-" and the last byte of the store item.
> This results in corruption of the bytes following that piece.
> 
> I've recently observed the splitting of store item names in *.zo files
> (see <https://bugs.gnu.org/47614>), but in that case the "-" was
> separated from the hash, and as a result the reference was _invisible_
> to the grafter.

Yes, I agree with this diagnosis.

It seems the discussion has become a bit fragmented, since Jack first 
reported one set of symptoms in <https://issues.guix.gnu.org/47064> and 
you then reported another in <https://issues.guix.gnu.org/47614> (with 
much better forensics than I'd found on my own—thanks!).

Both issues should have been fixed (at least with respect to Racket) by 
my patch in <https://issues.guix.gnu.org/47180>, which was applied on 
Monday.

-Philip