Date: Thu, 3 Feb 2022 09:17: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 Message-ID: <D93232D9-BCBF-4C65-B984-D95CB12ADFCD@yahoo.com> In-Reply-To: <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <FA290367-D4B6-463D-AC67-64F224B3C227@yahoo.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Feb-3, at 00:05, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Feb-2, at 17:51, bob prohaska <fbsd@www.zefox.net> wrote: >=20 >> On Wed, Feb 02, 2022 at 04:18:07PM -0800, Mark Millard wrote: >>> On 2022-Feb-2, at 14:32, bob prohaska <fbsd@www.zefox.net> wrote: >>>=20 >>>> The latest Pi3 single-user -j1 buildworld stopped with clang error = 139. >>>> Running the .sh and .cpp files produced an error. The .sh was >>>> re-run under lldb and backtraced. >>>=20 >>> I'll see if I can find any interesting information based on >>> the "fault address: 0x5" and source code related to the >>> backtrace reporting . >=20 > Between the source code and the assembler, I've yet > to see how the value 0x5 ended up as the address > used. >=20 >>>> The output is at >>>> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/lldb_session >>>> along with the buildworld log and related files in the same = directory. >>>=20 >>> Your 20220202/readme reports: >>>=20 >>> QUOTE >>> The first attempt to run lldb-gtest-all-fe760c.sh finished with = exit >>> code zero. A subsequent try produced the expected output reported >>> here in lldb_session. >>> END QUOTE >>>=20 >>> (You had also reported (off list) a recent prior failure where the >>> .sh/.cpp pair did not repeat the failure when you tired it.) >>>=20 >>> Well: >>>=20 >>> = http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/gtest-all-fe760c.o >>>=20 >>> seems to be a possibly valid compile result to go along with the >>> run (under lldb) that finished normally (exit code zero). >>>=20 >>> I can not see the dates/times on the files over the web interface. >>> Can you report the output of something like a >>>=20 >>> # ls -Tla >>=20 >> Done and added to the web directory as file_dates: >> root@pelorus:/usr/src # ls -Tla *76* >> -rw-r--r-- 1 root wheel 0 Feb 2 13:52:42 2022 = gtest-all-fe760c-d2733764.o.tmp >> -rw-r--r-- 1 root wheel 7339473 Feb 2 13:18:34 2022 = gtest-all-fe760c.cpp >> -rw-r--r-- 1 root wheel 5246192 Feb 2 13:48:41 2022 = gtest-all-fe760c.o >> -rw-r--r-- 1 root wheel 4527 Feb 2 13:18:34 2022 = gtest-all-fe760c.sh >> -rw-r--r-- 1 root wheel 1448 Feb 2 13:35:26 2022 = lldb-gtest-all-fe760c.sh >=20 > Thanks. That is the order for having a successful > gtest-all-fe760c.o generation when the lldb ran > the compile to completion with a zero status result > and later having the failing run. The gtest-all-fe760c.o > content is probably good. >=20 >>> We will see if I notice anything intersting looking at >>> source code related to the frames of the backtrace for >>> the lldb based failure reporting. >=20 > One of the odd things is that the bt command should > have reported a lot more frames than just #0..#5. > It should have gone all the way back to main and > __start and rtld_start . Another oddity that I've > no clue about at this point. >=20 >>> The variable results for the (lldb) .sh/.cpp runs for the >>> same file pair suggests possibilities like race conditions, >>> use of uninitialized memory, use of deallocated-and-reused >>> memory (now in-use for something else), flaky hardware. >>>=20 >>> (That failure only sometimes happened with the .sh/cpp >>> pair means that no processing of include files was involved: >>> the .cpp of the pair is self contained.) >>>=20 >>> I'll note that the buildworld.log 's : >>>=20 >>> 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:899:21: current parser token '{' >>> 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' >>>=20 >>> is the exact same places in the original source code >>> as was reported in other such logs for failures while >>> processing gtest-all.cc . >>>=20 >>>> Not sure what to try next. It is possible to build kernel-toolchain = and >>>> new kernels, >>>=20 >>> kernel-toolchain builds a subset of the toolchain that >>> buildworld builds. I'm unsure if the buildworld >>> completed building what kernel-toolchain builds or not. >>>=20 >>>> if that might be useful. >>>=20 >>> For now, I need to explore source code. >>>=20 >>=20 >> Ok, I'll refrain from idle tampering.=20 >=20 > Without being able to replicate the problem and explore > the context, I may well not get anywhere useful. >=20 > And nothing about this is suggesting any sort of work > around beyond building on a context that is not having > the issue and then installing from there to the media > that would be used on the RPi3* . >=20 >>>> At present the machine reports >>>> bob@pelorus:/usr/src % uname -apKU >>>> FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #0 = stable/13-n249120-dee0854a009: Sat Jan 22 23:32:23 PST 2022 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 = aarch64 1300525 1300523 >>>=20 >>> Thanks for the reference to stable/13 's dee0854a009 . >>>=20 >>> (This was still the "boot -s" single user context for >>> the testing. Note is for anyone reading this.) >>>=20 >>> FYI: the variable result makes the corrupted-block >>> hypothesis less likely. You have seen the failure via >>> the original files and via the .cpp of the .sh/.cpp >>> pair. You appear to have had a successful build >>> with the .cpp pair --and an unsuccessful one. Also >>> no stage under lldb reported illegal instructions or >>> the like. >>>=20 >=20 Could you make a copy of the /usr/bin/c++ involved accessible via: http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ (possibly compressed)? =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?D93232D9-BCBF-4C65-B984-D95CB12ADFCD>