Date: Thu, 27 Jun 2024 13:15:35 -0600 From: Warner Losh <imp@bsdimp.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Mark Millard <marklmi@yahoo.com>, FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7 Message-ID: <CANCZdfrALiptS-GMJHawxNXDJUfDxBrBvbL4xS8LUW6k%2BHQdJw@mail.gmail.com> In-Reply-To: <Zn2STr_KNhbWiXBY@www.zefox.net> References: <ZnNOXjgfyHQh7IeH@www.zefox.net> <5D5B6739-1685-43F5-80CC-E55603181D09@yahoo.com> <ZndZ9pVET2mCCpe8@www.zefox.net> <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> <ZngxCS22kAZSrWH4@www.zefox.net> <F05531C2-F2F3-463A-9E89-3EB8A5D714B6@yahoo.com> <ZntgkwPflE5S-Vhn@www.zefox.net> <C0E5C804-5B68-4D0B-883F-75FBCC8484EC@yahoo.com> <Zny1g_Ktg01_kQVV@www.zefox.net> <5DC2D33F-A8DB-4542-B8B3-A131F660A395@yahoo.com> <Zn2STr_KNhbWiXBY@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000049184e061be3f5ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2024 at 10:24=E2=80=AFAM bob prohaska <fbsd@www.zefox.net> = wrote: > On Wed, Jun 26, 2024 at 06:24:59PM -0700, Mark Millard wrote: > > > > Does using the chroot setup using --depth=3D1 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=3D 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. 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, don= e. > > > 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 > > > > > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > > > > > --00000000000049184e061be3f5ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 27, 2024 at 10:24=E2=80= =AFAM bob prohaska <<a href=3D"mailto:fbsd@www.zefox.net">fbsd@www.zefox= .net</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex">On Wed, Jun 26, 2024 at 06:24:59PM -0700, Mark Millard wrote:<br> > <br> > Does using the chroot setup using --depth=3D1 on the<br> > RPi2B consistently work when tried repeatedly? Or<br> > was this just an example of a rare success?<br> ><br> Apparently it was a rare success. Five back-to-back retries<br> all failed in an orderly way, though with different messages;<br> invalid fetch-pack and missing blob object.<br> The transcript is at<br> <a href=3D"http://www.zefox.net/~fbsd/rpi2/git_problems/readme_shallow_armv= 7_chroot_gittests" rel=3D"noreferrer" target=3D"_blank">http://www.zefox.ne= t/~fbsd/rpi2/git_problems/readme_shallow_armv7_chroot_gittests</a><br> <br> Is it worthwhile to repeat with different --depth=3D values? I'm not su= re<br> what the sensible range might be, maybe a 1, 2, 5 sequence? It would<br> be convenient to avoid a panic, as that slows repetition.<br></blockquote><= div><br></div><div>What happens if you start limiting the memory resources = inside a armv7 jail</div><div>on a aarch64 machine?</div><div><br></div><di= v>Sometimes it works, sometimes it doesn't triggers a "memory shor= tage" or</div><div>"marginal amounts of memory available" bu= g hunting memories for me.</div><div><br></div><div>Warner</div><div>=C2=A0= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"> Thanks for reading,<br> <br> bob prohaska<br> <br> <br> > > A second try without chroot resulted in failure but no panic:<br> > <br> > > <jemalloc>: Should own extent_mutex_pool(17)<br> > <br> > That looks like it would be interesting to someone<br> > appropriately knowledgeable. If jemalloc can see bad<br> > mutex ownerships, that seems like such could lead to<br> > all sorts of later problems: Garbage-in/garbage-out.<br> > <br> > I do not know if the message means that various<br> > corruptions might be in place afterwards so that<br> > various later problems might be consequences that<br> > are not surprising possibilities.<br> > <br> > > 47.25 MiB | 1.35 MiB/s=C2=A0 <br> > > error: index-pack died of signal 6<br> > > <br> > > A repeat session produced an oft-seen failure:<br> > > <br> > > root@www:/mnt # mkdir 3rdarmv7gittest<br> > > root@www:/mnt # cd 3rdarmv7gittest<br> > > root@www:/mnt/3rdarmv7gittest # git clone=C2=A0 -o freebsd ssh://= <a href=3D"http://anongit@192.158.248.9/src.git" rel=3D"noreferrer" target= =3D"_blank">anongit@192.158.248.9/src.git</a> .<br> > > Cloning into '.'...<br> > > remote: Enumerating objects: 4511481, done.<br> > > remote: Counting objects: 100% (383480/383480), done.<br> > > remote: Compressing objects: 100% (28955/28955), done.<br> > <br> > > <jemalloc>: Should own extent_mutex_pool(17)<br> > <br> > That is the same error notice as above that looked<br> > to be interesting.<br> > <br> > Note that it happens before the later message<br> > "error: index-pack died of signal 6". So that<br> > last may just be a later consequence of the<br> > earlier error(s).<br> > <br> > > 47.25 MiB | 1.35 MiB/s=C2=A0 <br> > > error: index-pack died of signal 6<br> > > fatal: index-pack failed<br> > > root@www:/mnt/3rdarmv7gittest # ls<br> > > root@www:/mnt/3rdarmv7gittest # cd ..<br> > > root@www:/mnt # mkdir 4tharmv7gittest<br> > > root@www:/mnt # cd 4tharmv7gittest<br> > > root@www:/mnt/4tharmv7gittest # git clone -o freebsd ssh://<a hre= f=3D"http://anongit@192.158.248.9/src.git" rel=3D"noreferrer" target=3D"_bl= ank">anongit@192.158.248.9/src.git</a> .<br> > > Cloning into '.'...<br> > > remote: Enumerating objects: 4511481, done.<br> > > remote: Counting objects: 100% (383480/383480), done.<br> > > remote: Compressing objects: 100% (28955/28955), done.<br> > > Receiving objects:=C2=A0 43% (1966916/4511481), 926.00 MiB | 626.= 00 KiB/s <br> > > remote: Total 4511481 (delta 377747), reused 354525 (delta 354525= ), pack-reused 4128001 (from 1)<br> > > Receiving objects: 100% (4511481/4511481), 1.64 GiB | 705.00 KiB/= s, done.<br> > > fatal: pack is corrupted (SHA1 mismatch)<br> > > fatal: index-pack failed<br> > <br> > Note the lack of a local message:<br> > <br> > <jemalloc>: Should own extent_mutex_pool<br> > <br> > But the prior jemalloc message(s) may be sufficient<br> > context to not be surprised about this.<br> > <br> > > root@www:/mnt/4tharmv7gittest # <br> > > <br> > > No panic, however, and it seems reproducible:<br> > > root@www:/mnt # mkdir 5tharmv7gittest<br> > > root@www:/mnt # cd 5tharmv7gittest<br> > > root@www:/mnt/5tharmv7gittest # git clone -o freebsd ssh://<a hre= f=3D"http://anongit@192.158.248.9/src.git" rel=3D"noreferrer" target=3D"_bl= ank">anongit@192.158.248.9/src.git</a> .<br> > > Cloning into '.'...<br> > > remote: Enumerating objects: 4511513, done.<br> > > remote: Counting objects: 100% (383480/383480), done.<br> > > remote: Compressing objects: 100% (28955/28955), done.<br> > > remote: Total 4511513 (delta 377756), reused 354525 (delta 354525= ), pack-reused 4128033 (from 1)<br> > > Receiving objects: 100% (4511513/4511513), 1.64 GiB | 1.28 MiB/s,= done.<br> > > fatal: pack is corrupted (SHA1 mismatch)<br> > > fatal: index-pack failed<br> > <br> > Note the lack of a local message:<br> > <br> > <jemalloc>: Should own extent_mutex_pool<br> > <br> > But the prior jemalloc message(s) may be sufficient<br> > context to not be surprised about this (again).<br> > <br> > > root@www:/mnt/5tharmv7gittest <br> > > <br> > > Not sure what to try next, thanks for reading this far! <br> > > <br> > > bob prohaska<br> > > <br> > > <br> > > Archived at <br> > > <a href=3D"http://www.zefox.net/~fbsd/rpi2/git_problems/readme_ar= mv7" rel=3D"noreferrer" target=3D"_blank">http://www.zefox.net/~fbsd/rpi2/g= it_problems/readme_armv7</a><br> > <br> > <br> > <br> > =3D=3D=3D<br> > Mark Millard<br> > marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_= blank">yahoo.com</a><br> > <br> > <br> <br> </blockquote></div></div> --00000000000049184e061be3f5ca--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrALiptS-GMJHawxNXDJUfDxBrBvbL4xS8LUW6k%2BHQdJw>