Date: Thu, 3 Feb 2022 00:05:42 -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: <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> In-Reply-To: <20220203015149.GA78722@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Feb-2, at 17:51, bob prohaska <fbsd@www.zefox.net> wrote: > 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 . Between the source code and the assembler, I've yet to see how the value 0x5 ended up as the address used. >>> 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 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. >> 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. 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. >> 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 Without being able to replicate the problem and explore the context, I may well not get anywhere useful. 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* . >>> 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 =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?8A85F917-F4E8-4382-B777-15AF7401E616>