Date: Fri, 4 Feb 2022 19:18:06 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] Message-ID: <22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0@yahoo.com> In-Reply-To: <AF33B536-3CF5-494D-B279-80DC60EF9B39@yahoo.com> References: <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <D93232D9-BCBF-4C65-B984-D95CB12ADFCD@yahoo.com> <C3D8ABCB-C7CC-4D88-B648-7C31C5BCC96E@yahoo.com> <20220204214403.GA85107@www.zefox.net> <B5FD0DF9-283E-49F1-BF73-2D8675B3E72E@yahoo.com> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> <20220205020612.GA85996@www.zefox.net> <AF33B536-3CF5-494D-B279-80DC60EF9B39@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Feb-4, at 18:54, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Feb-4, at 18:06, bob prohaska <fbsd@www.zefox.net> wrote: >=20 >> On Fri, Feb 04, 2022 at 05:00:05PM -0800, Mark Millard wrote: >>> On 2022-Feb-4, at 16:08, bob prohaska <fbsd@www.zefox.net> wrote: >>>=20 >>>> On Fri, Feb 04, 2022 at 02:44:01PM -0800, Mark Millard wrote: >>>>> On 2022-Feb-4, at 13:44, bob prohaska <fbsd@www.zefox.net> wrote: >>>>>=20 >>>>=20 >>>> It sounds like I simply have a corrupted c++. Perhaps just >>>> set the old version aside and copy from the chroot directory >>>> to /usr/bin ? Granted, other things might be wrong as well.=20 >>>=20 >>> I'm not so sure. My expectation is that if you first >>> do (presuming not already in place at the time): >>>=20 >>> # sysctl kern.elf64.aslr.enable=3D0 >>>=20 >> On checking, that's already the case. I didn't change it >> knowingly, likely it's been zero all along. >=20 > So you get the failures even when: >=20 > # sysctl kern.elf64.aslr.enable > kern.elf64.aslr.enable: 0 >=20 > ? >=20 > That is different than in my context. I've never > gotten the failure for the above type of context. >=20 > It may be that for stable/13 's kernel the > default is 0 . I looked at the source and it does default to 0 for stable/13 's source vintage that I have. It is too late now for an immediate test, but at some point after a reboot that has the value 0 in kern.elf64.aslr.enable still, try looking at: # sysctl vm.aslr_restarts before and after the .sh/.cpp testing that shows failures. If the value becomes non-zero at any point then some ASLR activity was attempted despite the 0 in kern.elf64.aslr.enable . > I did test and one can actually set: >=20 > kern.elf64.aslr.enable >=20 > from inside a chroot context, at least > when one generally works as root. It > changed the system's overall > kern.elf64.aslr.enable status. >=20 >>> and then to your buildworld buildkernel it will just work >>> -- using your exising c++ compiler (system clang/clang++). >>>=20 >> Well, that hasn't happened yet. On the theme that if a >> problem won't get better find out what makes it worse, >> I've set it to 1 and am re-running buildworld with -j1. >=20 > Okay. That you get the failures even when > kern.elf64.aslr.enable is 0 means that my > existing context for investigation is > still problematical. >=20 >>>=20 >>> It seems very odd that such a setting would "uncorrupt" >>> your clang/clang++ build (used under the name c++). I'm >>> not aware of the compiler doing anything like the ntpd >>> did, for which having ASLR enabled as a problem. >>>=20 >>> For far as I can tell, the setting changes the detailed >>> behavior of mmap calls (including implicit ones in >>> library code and such). >>>=20 >>> I've not found a way to look at the context just before >>> the failure (without disturbing things enough via debugger >>> activity that the failure does not happen). It is likely >>> that I'll not manage to get such evidence that includes >>> the failure. >>>=20 >>> I worry that the failures seen with your c++ involves a >>> kernel bug but I do not see a way to investigate that. >>=20 >> I share your feeling that something isn't right but am >> utterly ill equipped to posit what that might be. The=20 >> most obvious recent strangeness with outbound network >> traffic not working unless accompanied by an outbound >> ping is most peculiar.=20 >>=20 >>=20 >> Might this be a reason to try Peter Holm's stress2 suite? I >> haven't played with it in a long time, not sure it'll even >> compile now. "Success" in stress2 terms is a kernel panic. >=20 > main [so: 14] has: >=20 > # ls -Tld /usr/main-src/tools/test/stress2/ > drwxr-xr-x 8 root wheel 33 Apr 28 15:20:54 2021 = /usr/main-src/tools/test/stress2/ >=20 > But I'm not sure if it would be of any help or not. > It may not have tests for causing vm.aslr_restarts > to increment during operation and then seeing > what works vs. what does not. >=20 > stable/13 and before do not seem to have stress2/ . >=20 >>> Another option might be to use a copy of the >>> compiler from the chroot area to replace the >>> normal system's copies, possibly renaming the >>> old ones first (various names), including >>> deal with clang.debug as well. This presumes >>> that the 2 stable/13 builds are sufficiently >>> compatible for such a substitution to work. >>=20 >> That sounds worth a try if no better ideas emerge. >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0>