From nobody Thu Feb 03 01:51:49 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 26C2F198F1B0 for ; Thu, 3 Feb 2022 01:51:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jq1ql6wlzz3lRK for ; Thu, 3 Feb 2022 01:51:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2131poE7078817 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 2 Feb 2022 17:51:50 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 2131poID078816; Wed, 2 Feb 2022 17:51:50 -0800 (PST) (envelope-from fbsd) Date: Wed, 2 Feb 2022 17:51:49 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Troubles building world on stable/13 Message-ID: <20220203015149.GA78722@www.zefox.net> References: <20220121031601.GA26308@www.zefox.net> <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> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> X-Rspamd-Queue-Id: 4Jq1ql6wlzz3lRK X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [2.59 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.01)[-0.007]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.28)[-0.283]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.98)[0.979]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 02, 2022 at 04:18:07PM -0800, Mark Millard wrote: > On 2022-Feb-2, at 14:32, bob prohaska wrote: > > > 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. > > I'll see if I can find any interesting information based on > the "fault address: 0x5" and source code related to the > backtrace reporting . > > > 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. > > Your 20220202/readme reports: > > 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 > > (You had also reported (off list) a recent prior failure where the > .sh/.cpp pair did not repeat the failure when you tired it.) > > Well: > > http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/gtest-all-fe760c.o > > seems to be a possibly valid compile result to go along with the > run (under lldb) that finished normally (exit code zero). > > I can not see the dates/times on the files over the web interface. > Can you report the output of something like a > > # ls -Tla 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 > > 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. > > 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. > > (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.) > > I'll note that the buildworld.log 's : > > 1. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:899:21: current parser token '{' > 2. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:58:1: parsing namespace 'testing' > > is the exact same places in the original source code > as was reported in other such logs for failures while > processing gtest-all.cc . > > > Not sure what to try next. It is possible to build kernel-toolchain and > > new kernels, > > 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. > > > if that might be useful. > > For now, I need to explore source code. > Ok, I'll refrain from idle tampering. > > 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 > > Thanks for the reference to stable/13 's dee0854a009 . > > (This was still the "boot -s" single user context for > the testing. Note is for anyone reading this.) > > 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. > > === > Mark Millard > marklmi at yahoo.com > >