Date: Wed, 23 Jun 2021 16:22:35 -0700 From: Mark Millard via freebsd-ports <freebsd-ports@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD ports <freebsd-ports@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: llvm10 build failure on Rpi3 Message-ID: <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> In-Reply-To: <20210623222838.GA85566@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <DD8D8FE1-F02E-4A25-8F2B-5672F10E7268@yahoo.com> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jun-23, at 15:28, bob prohaska <fbsd at www.zefox.net> wrote: > On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote: >> On 2021-Jun-23, at 10:43, bob prohaska <fbsd at www.zefox.net> wrote: >>=20 >>> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote: >>>>=20 >>>> Not that it helps much, but: 2779096485 =3D=3D 0xA5A5A5A5 >>>>=20 >>>> It appears that such somehow was involved-in/generated by: >>>>=20 >>>> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && = /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen = -gen-global-isel -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU = -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >>>>=20 >>>> and that lead to the commented out notation in the output, with the = "@2779096485" listed in the comment as well. >>>>=20 >>>=20 >>> A Pi4 doing a bulk build of chromium, lxqt and apache has gone far = past that >>> point building llvm10, suggesting the fault lies somewhere in my = setup. >>=20 >> I'm not so sure of that for the 0xA5A5A5A5u value. You run >> main [so: 14 at this point]. Is it a debug build? Or a >> non-debug build? I expect that 0xA5A5A5A5u has some specific >> debug-build potential meaning. >>=20 > The kernel in use is=20 > FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n247405-8fa5c577de3: Fri Jun 18 17:03:19 PDT 2021 = bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM = arm64 > and it can invoke the debugger using [enter]-tilda-control-b. If it was a normal style build of main-n247405-8fa5c577de3 then both the kernel and world would be debug builds. But it is possible to explicitly control if MALLOC_PRODUCTION is used instead and the like, based on how doing the build was configured. (Lots more can be controlled for the builds.) I still can not tell if it was a debug (normal) main build or not. I would guess it was a normal debug build, no extra disabling or enabling of such. Side Note: Going in a separate direction: do you also run main on faster aarch64 systems (RPi4B's)? Do you also build there? If so, it is possible to make a copy of the poudriere/data/packages/main-default/ tree from the fast system on the slower system and then use pkg on the slower system without doing builds there. It is also possible to set up to have the fast system be used as a remote source of the packages, much like FreeBSD servers. But I've never done such. Based on what you have done to publish for folks to look at when they are helping, you might (mostly?) already have that set up, other than pointing package to the right URL on the slower machine. End Side Note. >> For example, 0xA5u byte values might be the value that newly >> allocated memory is initialized to. Looking . . . man jemalloc >> (the memory allocator implementation used by FreeBSD) reports: >>=20 >> opt.junk (const char *) r- [--enable-fill] >> Junk filling. If set to ???alloc???, each byte of = uninitialized >> allocated memory will be initialized to 0xa5. If set to = ???free???, all >> deallocated memory will be initialized to 0x5a. If set to = ???true???, >> both allocated and deallocated memory will be initialized, = and if >> set to ???false???, junk filling be disabled entirely. This = is intended >> for debugging and will impact performance negatively. This = option >> is ???false??? by default unless --enable-debug is = specified during >> configuration, in which case it is ???true??? by default. >>=20 >> So, if you have junk filling enabled, I expect that you ran >> into a legitimate defect in the llvm-tblgen in use. Having >> Junk Filling disabled might be a workaround. >>=20 >> There is /etc/malloc.conf as a way of controlling the behavior: >>=20 >> ln -s 'junk:false' = /usr/local/poudriere/poudriere-system/etc/malloc.conf >>=20 >> I suggest you retry building after getting the above in place. >> If it does not get the 0xA5A5A5A5u value, that would be >> more evidence of a uninitialized-memory defect in the llvm-tblgen >> involved. >>=20 > Done and running now. In the interim I tried building llvm10 using > make in /usr/ports, but it failed with another python conflict. Intersting. I'm unable to see a: /usr/local/poudriere/poudriere-system/etc/malloc.conf via what you have published. But I've no clue if such an odd symbolic link would be expected to show up. >> I do not normally run debug builds and so would not have >> run into 0xA5A5A5A5u from Junk Filling of memory allocations. >>=20 >> I'm not sure when I can setup and do a junk filling experiment >> (in a debug main build?). But it looks like some independent >> compare/contrast activity might be appropriate. >>=20 >>> The instructions you gave for setting up poudriere seemed to work = perfectly >>> initially, but since that time both world and kernel have been = updated >>> along with ports. Is it necessary or advisable to alter = /usr/local/poudriere, >>> either by update commands or complete replacement?=20 >>=20 >> I will note that your log file reports: >>=20 >> Host OSVERSION: 1400023 >> Jail OSVERSION: 1400019 >>=20 >> So your jail's OSVERSION is older than the environment >> that it is running in. (Unlikely to contribute to the >> 0xA5A5A5A5u as far as I can tell.) In other words, you >> have not updated your: >>=20 >> /usr/local/poudriere/poudriere-system/ >>=20 >> to 1400023 as far as I can tell. >>=20 >=20 > After one of the world/kernel rebuilds I attempted to repeat your > poudriere setup instructions, thinking it would update the setup. > IIRC both commands were refused, not with an error, but more like > a "don't do that" sort of message. I fumbled for a while with > poudriere ports -u, but couldn't get the syntax right. Then I > noticed a reference to null-mounting /usr/ports, which strongly > suggested any updates to ports would be picked up by default.=20 The steps in question for my point are (from your http://www.zefox.org/~bob/readme ): # cd /usr/src # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distrib-dirs DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distribution DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 Your: cd /usr/local/poudriere # poudriere ports -c -m null -M /usr/ports # poudriere jail -c -j main -m null -M = /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT leaves /usr/ports/ and /usr/src/ automatically bound to the most recent content from the system. But the installworld related material is not automatic. (And poudriere should not point at the live system's own materials for such: during operation it temporarily changes some things in the system it is pointed at.) >> Separately from that, for poudriere itself: >>=20 >=20 >> I do not know if you are using ports-mgmt/poudriere-devel vs. >> ports-mgmt/poudriere .=20 >=20 > Poudriere version reports 3.3.6. I believe it's _not_ the -devel = version. Okay. I've always used poudriere-devel . No reason that you should but now I know that we can have some distinctions for poudriere itself for recent functionality. >> But, whichever, it is a port and is >> one of the ports that should be built when it has updated >> when you update /usr/ports content and should then have its >> install be updated via pkg like the other ports. >>=20 >=20 > I've yet to master getting pkg to actually work from a local = repository. > The handbook says to create=20 > /usr/local/poudriere % more /usr/local/etc/pkg/repos/FreeBSD.conf > containing > FreeBSD: { > enabled: no > } That is part of it. I have: # find /usr/local/etc/pkg/repos/ -print /usr/local/etc/pkg/repos/ /usr/local/etc/pkg/repos/FreeBSD.conf /usr/local/etc/pkg/repos/custom.conf # more /usr/local/etc/pkg/repos/custom.conf=20 custom: { url: = "file:///usr/local/poudriere/data/packages/13_0R-CA72-default", enabled: yes, } The file:// prefix is URL notation and the rest is the directory path, including its leading / . So, for your context: custom: { url: "file:///usr/local/poudriere/data/packages/main-default", enabled: yes, } I'll note that the default for remote use of the FreeBSD servers looks like: # more /etc/pkg/FreeBSD.conf=20 # $FreeBSD$ # # To disable this repository, instead of modifying or removing this = file, # create a /usr/local/etc/pkg/repos/FreeBSD.conf file: # # mkdir -p /usr/local/etc/pkg/repos # echo "FreeBSD: { enabled: no }" > = /usr/local/etc/pkg/repos/FreeBSD.conf # FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } So something somewhat similar likely could be used in /usr/local/etc/pkg/repos/custom.conf to use a faster machine's packages via a slower machine's pkg, without coying over the directory tree that contains the respository. > Hopefully, using=20 > pkg install -r /usr/local/poudriere/data/packages/main-default/All = [pkgname] > will do the trick. Any cautionary tales would be much appreciated.=20 With an appropriate /usr/local/etc/pkg/repos/custom.conf you should be able to use pkg normally. The pkg install -r installs more than needed and not in a way that pkg autoremove would clean up. When you get pkg working with /usr/local/poudriere/data/packages/main-default/ material, you might want to do a round of deleting the installs and then only explicitly installing the things that you directly want to use. The rest needed at run-time should automatically install, but in a way that would allow for a later autoremove to work for things that are no longer being used after an update. >> I list ports-mgmt/poudriere-devel in the file with the other >> ports that I list in ~/origins/CA72-origins.txt and I use >> that file via -f in the bulk command. >>=20 >=20 > If there's a guide to using poudriere/pkg in a self-hosting situation > it would be very useful. The existing docs have a very different = focus. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8E78EE69-44A2-429E-AB65-941537DE25A0>