Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7

From: bob prohaska <fbsd_at_www.zefox.net>
Date: Thu, 27 Jun 2024 16:24:46 UTC
On Wed, Jun 26, 2024 at 06:24:59PM -0700, Mark Millard wrote:
> 
> Does using the chroot setup using --depth=1 on the
> RPi2B consistently work when tried repeatedly? Or
> was this just an example of a rare success?
>
Apparently it was a rare success. Five back-to-back retries
all failed in an orderly way, though with different messages;
invalid fetch-pack and missing blob object.
The transcript is at
http://www.zefox.net/~fbsd/rpi2/git_problems/readme_shallow_armv7_chroot_gittests

Is it worthwhile to repeat with different --depth= values? I'm not sure
what the sensible range might be, maybe a 1, 2, 5 sequence? It would
be convenient to avoid a panic, as that slows repetition. 

Thanks for reading,

bob prohaska

 
> > A second try without chroot resulted in failure but no panic:
> 
> > <jemalloc>: Should own extent_mutex_pool(17)
> 
> That looks like it would be interesting to someone
> appropriately knowledgeable. If jemalloc can see bad
> mutex ownerships, that seems like such could lead to
> all sorts of later problems: Garbage-in/garbage-out.
> 
> I do not know if the message means that various
> corruptions might be in place afterwards so that
> various later problems might be consequences that
> are not surprising possibilities.
> 
> > 47.25 MiB | 1.35 MiB/s  
> > error: index-pack died of signal 6
> > 
> > A repeat session produced an oft-seen failure:
> > 
> > root@www:/mnt # mkdir 3rdarmv7gittest
> > root@www:/mnt # cd 3rdarmv7gittest
> > root@www:/mnt/3rdarmv7gittest # git clone  -o freebsd ssh://anongit@192.158.248.9/src.git .
> > Cloning into '.'...
> > remote: Enumerating objects: 4511481, done.
> > remote: Counting objects: 100% (383480/383480), done.
> > remote: Compressing objects: 100% (28955/28955), done.
> 
> > <jemalloc>: Should own extent_mutex_pool(17)
> 
> That is the same error notice as above that looked
> to be interesting.
> 
> Note that it happens before the later message
> "error: index-pack died of signal 6". So that
> last may just be a later consequence of the
> earlier error(s).
> 
> > 47.25 MiB | 1.35 MiB/s  
> > error: index-pack died of signal 6
> > fatal: index-pack failed
> > root@www:/mnt/3rdarmv7gittest # ls
> > root@www:/mnt/3rdarmv7gittest # cd ..
> > root@www:/mnt # mkdir 4tharmv7gittest
> > root@www:/mnt # cd 4tharmv7gittest
> > root@www:/mnt/4tharmv7gittest # git clone -o freebsd ssh://anongit@192.158.248.9/src.git .
> > Cloning into '.'...
> > remote: Enumerating objects: 4511481, done.
> > remote: Counting objects: 100% (383480/383480), done.
> > remote: Compressing objects: 100% (28955/28955), done.
> > Receiving objects:  43% (1966916/4511481), 926.00 MiB | 626.00 KiB/s 
> > remote: Total 4511481 (delta 377747), reused 354525 (delta 354525), pack-reused 4128001 (from 1)
> > Receiving objects: 100% (4511481/4511481), 1.64 GiB | 705.00 KiB/s, done.
> > fatal: pack is corrupted (SHA1 mismatch)
> > fatal: index-pack failed
> 
> Note the lack of a local message:
> 
> <jemalloc>: Should own extent_mutex_pool
> 
> But the prior jemalloc message(s) may be sufficient
> context to not be surprised about this.
> 
> > root@www:/mnt/4tharmv7gittest # 
> > 
> > No panic, however, and it seems reproducible:
> > root@www:/mnt # mkdir 5tharmv7gittest
> > root@www:/mnt # cd 5tharmv7gittest
> > root@www:/mnt/5tharmv7gittest # git clone -o freebsd ssh://anongit@192.158.248.9/src.git .
> > Cloning into '.'...
> > remote: Enumerating objects: 4511513, done.
> > remote: Counting objects: 100% (383480/383480), done.
> > remote: Compressing objects: 100% (28955/28955), done.
> > remote: Total 4511513 (delta 377756), reused 354525 (delta 354525), pack-reused 4128033 (from 1)
> > Receiving objects: 100% (4511513/4511513), 1.64 GiB | 1.28 MiB/s, done.
> > fatal: pack is corrupted (SHA1 mismatch)
> > fatal: index-pack failed
> 
> Note the lack of a local message:
> 
> <jemalloc>: Should own extent_mutex_pool
> 
> But the prior jemalloc message(s) may be sufficient
> context to not be surprised about this (again).
> 
> > root@www:/mnt/5tharmv7gittest 
> > 
> > Not sure what to try next, thanks for reading this far! 
> > 
> > bob prohaska
> > 
> > 
> > Archived at 
> > http://www.zefox.net/~fbsd/rpi2/git_problems/readme_armv7
> 
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
>