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

bob prohaska <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
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://[email protected]/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://[email protected]/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://[email protected]/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
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.