RPI3 clang crashes in buildworld

[Mark Millard]

On 2019-Jan-20, at 15:47, bob prohaska <fbsd at www.zefox.net> wrote:

> On Sun, Jan 20, 2019 at 01:39:04PM -0800, Mark Millard wrote:
>> On 2019-Jan-20, at 08:32, bob prohaska <fbsd at www.zefox.net> wrote:
>> 
>> 
>>> Has anyone had recent success running buildworld on an RPI3? I'm seeing
>>> signal 11's with increasing regularity during the building libraries phase.
>>> Two months ago -j4 buildworld ran successfully.
>>> 
>>> It's possible my system is corrupted. I've tinkered with  a kernel patch at
>>> https://people.freebsd.org/~gonzo/arm/patches/vchiq-wip-20180217.diff
>>> back when the system was at r342781, but the patch was reversed and the
>>> machine is now up to r343165 using "clean start" buildworld without -j
>>> and careful restarts, deleting the last .o file before the crashes.
>>> 
>>> There are no hardware errors on the console and only clang is crashing.
>>> The machine will even run the chromium browser without crashing, but it
>>> does grumble:
>>> 
>>> bob at www:~ % chrome
>>> [83827:1218383872:0120/075747.927080:ERROR:gpu_process_transport_factory.cc(1016)] Lost UI shared context.
>>> [84111:1339003392:0120/075753.574384:ERROR:command_buffer_proxy_impl.cc(113)] ContextResult::kFatalFailure: Shared memory handle is not valid 
>>> 
>>> The most recent buildworld steps were 
>>> svnlite up /usr/src
>>> make cleandir (twice)
>>> rm -rf /usr/obj/usr/
>>> make kernel-toolchain
>>> make buildkernel
>>> make installkernel
>>> (reboot)
>>> make buildworld (using -DNO_CLEAN for restarts)
>>> 
>>> Have I taken all the steps possible for a clean rebuild?
>>> 
>>> At the moment both buildworld and chromium are running, without 
>>> any additional problems.
>> 
>> 
>> You may want to give more details, such as the content of . . .
>> 
>> /etc/make.conf
>> /etc/src.conf
>> *.meta files for the failed commands (if any)
>> 
>> Listing some example *.meta file information from a cross build
>> (not likely problem files):
>> 
>> # cd /usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/bin/sh
>> # ls -lTdrt *.meta
>> . . .
>> -rw-r--r--  1 root  wheel  4236 Dec 11 23:42:04 2018 nodes.o.meta
>> -rw-r--r--  1 root  wheel  3603 Dec 11 23:42:05 2018 sh.full.meta
>> -rw-r--r--  1 root  wheel   726 Dec 11 23:42:05 2018 sh.debug.meta
>> -rw-r--r--  1 root  wheel   739 Dec 11 23:42:05 2018 sh.meta
>> 
> 
> All are absent. /etc/src.conf and /etc/make.conf have been used in the
> past but subsequently renamed to inactivate them.

Good to know.

> Using
> find /usr/obj -name \*.meta -depth -print 
> reports nothing, did I botch the wildcard escape? 
> Note that this is arm64, not armv7, does that matter?

The build attempt itself creates the *.meta files when WITH_META_MODE=
is in use. But I forgot that WITH_META_MODE is not enabled by default.

WITH_META_MODE has to be supplies via an environment variable style of
definition if used:

QUOTE
     The environment of make(1) for the build can be controlled via the
     SRC_ENV_CONF variable, which defaults to /etc/src-env.conf.  Some
     examples that may only be set in this file are WITH_DIRDEPS_BUILD, and
     WITH_META_MODE, and MAKEOBJDIRPREFIX as they are environment-only
     variables.
END QUOTE

It can be supplied as a prefix on the make command line. For example I use
in a script file (/bin/sh notation):

env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" SRC_ENV_CONF="/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-host" \
WITH_META_MODE=yes \
WORLD_FLAGS="${WORLD_FLAGS} UBLDR_LOADADDR=0x42000000" \
MAKEOBJDIRPREFIX="/usr/obj/armv7_clang/arm.armv7" \
make $*

(Not that you need all of the env value specifications above or the
$* notation on a direct command on the command line.)

As to why you might want such a WITH_META_MODE build:

QUOTE
     WITH_META_MODE
. . .
. . . These meta files track the
             command that was executed, its output, and the current directory.
             The filemon(4) module is required unless NO_FILEMON is defined.
. . .
             The meta files can also be useful for debugging.

             The build hides commands that are executed unless NO_SILENT is
             defined.  Errors cause make(1) to show some of its environment
             for further debugging.
. . .
             This must be set in the environment, make command line, or
             /etc/src-env.conf, not /etc/src.conf.
END QUOTE

The quotes are from "man src.conf". WITH_META_MODE is designed to give
incremental builds once the initial META_MODE build has been established.


> The system seems to do most of its crashing when making .pico files.
> It's been building libraries for a couple of hours, if past 
> experience is any guide it'll finish in a couple of days.

Getting the the records in *.meta files would require starting a new
from-scratch build using WITH_META_MODE.

I warn that WITH_META_MODE=no would also enable the mode: the issue is
if WITH_META_MODE is defined vs. not, instead of being the specific value
assigned.

One thing that can help with avoiding excessive memory use is:

LDFLAGS.lld+= -Wl,--no-threads

in order to avoid ncpu+2 threads going in parallel during a specific
link, so 4+2 in your context for one link. If more than one link
runs at once it ends up being nlinksatonce*(4+2) threads at the
same time. So for -j4 it could end up with 4*6==24 threads at once
(and I've seen such things).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)