Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone]

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