Date: Fri, 4 Feb 2022 14:44:01 -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: <B5FD0DF9-283E-49F1-BF73-2D8675B3E72E@yahoo.com> In-Reply-To: <20220204214403.GA85107@www.zefox.net> References: <FBD31544-6D8F-40DB-BC36-F0B2BBA78A14@yahoo.com> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Feb-4, at 13:44, bob prohaska <fbsd@www.zefox.net> wrote: > On Thu, Feb 03, 2022 at 02:05:38PM -0800, Mark Millard wrote: > [chroot setup snipped] >> >> It would be good to know what experiments produce relative to >> failures vs. successes: all one? the other? a mix? Part of the >> point here is to test builds from official FreeBSD build >> servers instead of personal builds. >> > > I placed the chroot directory under a regular (wheel group) login, > but otherwise followed the instructions successfully, I think. > Since all the installed files were owned by root, I used the > root login to work in the chroot. > > Five attempts to run the .sh/.cpp file produced all successful > results. Interesting. Currently it looks like your specific compiler build and the ASLR (Address Space Layout Randomization) somehow interact, leading to sometimes getting the SIGSEGV's. I have only reproduced the problem with the copy of your c++ -- but it stops reproducing in my environment when I disable the system's ASLR mode of operation. You got later messages about the ASLR disabling experiments that I did. > Next I tried to use lldb. That produced the usual > preliminary output. However, on issuing the run command I got > > error: DupDescriptor-open failed: No such file or directory > That message happens when devfs has not been set up for the dev directory inside the chroot. In my instructions, before the chroot command, there was: # mount -tdevfs devfs ~/13S-chroot/dev that set up the dev that was in 13S-chroot/ . It does not survive reboots and needs to be done again after a reboot --from outside any chroot session. In my context, the following shows some checkable consequences of a correct, active devfs mount: # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/Rock64root 823229 194087 563283 26% / devfs 0 0 0 100% /dev # mount -t devfs devfs ~/13S-chroot/dev # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/Rock64root 823229 194087 563283 26% / devfs 0 0 0 100% /dev devfs 0 0 0 100% /root/13S-chroot/dev Of course, you did not use a /root/ base for where you put your equivalent of 13S-chroot/ and may not have had a context where ~/ referenced where you put your equivalent of 13S-chroot/ . So adjust notation as possibly required. You can use df -m to confirm the devfs status before doing the chroot command into the chroot area. I do not know if there are any consequences to the ownership of your equivalent of 13S-chroot/ . === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B5FD0DF9-283E-49F1-BF73-2D8675B3E72E>