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

Reply: Mark Millard : "Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7"
In reply to: Warner Losh : "Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Thu, 27 Jun 2024 21:40:33 UTC
On Jun 27, 2024, at 12:15, Warner Losh <imp@bsdimp.com> wrote:

On Thu, Jun 27, 2024 at 10:24 AM bob prohaska <fbsd@www.zefoxnet> wrote:
> 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.
> 
> What happens if you start limiting the memory resources inside a armv7 jail
> on a aarch64 machine?
> 
> Sometimes it works, sometimes it doesn't triggers a "memory shortage" or
> "marginal amounts of memory available" bug hunting memories for me.

As I reported in a earlier submittal to the list, I've
replicated the problem on an armv7 system running main [15]
with RAM+SWAP being:

2048 MiBytes RAM + 3685 MiBytes SWAP == 5733 MiBytes OVERALL

This was on a Orange Pi+ 2ed. A top variation monitoring and
reporting various maximum observed figures did not show any
large memory use compared to even 1024 MiBytes. Any limitation
would appear to have to be local to some more specific kind
of constraint rather than overall system RAM or RAM+SWAP.

> Warner
>   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
> > 
> > 
> 

===
Mark Millard
marklmi at yahoo.com