From nobody Thu Feb 3 08:05:42 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 D011119B1311 for ; Thu, 3 Feb 2022 08:05:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqB7Q6f38z4ZY2 for ; Thu, 3 Feb 2022 08:05:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643875547; bh=ZzRCUVcw7zAW5ZPKS6VIZOU7qrA10niJx523tibii38=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mMs5/5OnzRyLONoZKiAuV5QXDqo0chrSNYM6XGyrM20tnnr/xL0fZlBPw140Z80HkiOgcv2+Q7u++aJ6A4bEuxbFA3z/ttI1YRF5b1W0Pv5S3BiQiU8paLrYyU3zLVxBvuL99OXY8dEtXdK4NihaR9EQzej29priXuI3XLs138wJMswfE2u3vpNsQYS2q56y8o7NhDfasoiaNqKph0bkfNHqdYwVF4253N3qGKVjRj5BBQlJ/LcEYhgl+dvZ7Qx/aLwO6Acqzft6BYKv3wtNNE80Jf1c3g6rGYCmeux8I9FBT+bVj3ZJTWCT6oLRSyk+geZhRkdIes1tCbdJDNqzBw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643875547; bh=ffc3CDFB9aNQjTfUMvpdz63iD7vuG2laSZLBbGNg/SQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cUxyK1E0d+1jXL5ahWDHBih+clOCk0P4gkCnXIbeOXiY5zcbeXgPatPENZsGTiT4xHKpdvDfy4XB/9J+Vh07czXsXhS8f3A8atJ11rPteOPgEA7+LbWCshzRODUoYinvpzeDCL75oVP6qeQwDdSaFDHDMLW3iBo4L4gxCn6hQUmonNT2IIzczQbsgBIyqxHmia/czDjKCnz/9/ptM+goVnahIQ8E1QhzZnWh0/7UWxX22DjS4Gu1bmmbA69xcE95QT88hVdI5sh8tsQKX5l9YkCZxRw5aIBMBPAta/8902jwPOxgL9P9g8nqI++Ti0+RDmfHy2exN+y5B3dvtTvqaw== X-YMail-OSG: Cy5Yj3QVM1m6c_stMC_xcHoi9HGB5kueuTbGXiYieHxUTpWSbsjCUmsz6XIRCpQ 5z8JbgZGVKuTkR7joLB6byUJaokgzmtnoDN6Au.BNXMjKYzNpaSvIUUZuvMjrfmQp9UH.ONjQHDN HReGE9xiPpihOtsLwn8d5WYXSBy3lqMh1QW4mpdugtrtv6B1gr7SLBhsJdm5yTve_AkFIHGcf0G7 emkA44pqvO5ftFMgQOb2YlhQJEuRFnyZditL33ZGyR07Cbn0JTz86XPFfGmlHHh50Ctz2xnVMHYi 5Mybi81CMz2hAHd0Nj4RhQtiWQIc9EE47InkYlss_1tEWusUYT6ViGD7idEGnBhkjT.zVCSoVIr6 _e7NRE7hKTH8vGDDkKqubHIPGukGojQe2sJFleJRDqi.fJYpz3P1JFkgyXbbpdW8bDCIUY3lE_rE Z41YMlp9SSijtOQz6cT.IsjHO_9Tqnz4C6oQi9oSb4GSHWAmTVd1EQSdhG5.kRXmYppsTX8TAFbK Xczp2AhOgIMzYP27hynOubWCcHM4CBsnM7yWQc1hjeM86cQClJZoSDLnJV.ZpoIAX9ecPIWFX0Eh 9PrSZIP9Z3_akvZHPVuX3HIHFtV5H72G5iQIIMS.mabQnrPPAYSXpyKuS51xJiE_b55RckylHPml T4AAwO2G3IDG6h57Iw4_8Jq0EbnfeAQeMKTwwSaRh7PRGHDCWwH2yvikGICkB133Wxor_uO2u5II teoiWKurS7zXWo_YQNvLgik8DnW73nBBGz.RWWsAAtiblLdP9F5V4PjheIst3HkbveXjcLOOS_6z hxn1_lKmHPsVnWUduE5tUBqOjm8SJKeUrX3MjpY9_hd9cXL1IWnzJK58yf2GC.IV7T3LyQZsryDA jbGUqPyvZdOkDNx0UJQuV65qIqYVqOxbBATtn9eZL397rSql8.Y1v_wn3cgdZOQazAbVX0WFBikv Z8zRtpHEyU0SwVMGzHFIH2_zeLEZWkEjBP9WEzkdtGTMPDw9ILsb0qfSLXN.T3zyMdg9j5USZ2Ck oOG9j2C3A2.kJgXlsp6dKFhXuQni8GLAmaYbviQkEk8LpsIsGfBolvv0_zU87pXBjp8G6EUdYE2L biHeBKhxpR16ZqGGTJeHTVdsClgiGvZyxvqMzSEfSb_Q3sr.w5BQHPNRZdcNz0XsQS11JiBBafan Yx8w5wLnnVXh9WsvxHYccOrX.VFieT8d9fF53O2m9gMVg3qq_skKKVdIWxMoZ26tPlhfWJqEujkk V0AqIE_21X_U938HpaULbaFVJ5eFKI635yHl7vgYeppzXwUTdAeB1FSjUrqLauLgIMShPzYkKaaL tZL74Edf9Ibdl0fg9FBbw0oSUC9RDLrrPkBuhO0bZKTWP23eLhgFj3RYSSEZVKemeQIL4.zn_1D1 xvGJiCeXXiXjlR77W1qanBQCRMJ9K3wpl6iLk1CgjZTRi8mqRmJEdcT9Qw8KYb8wb9nc79ptBN3B iCeOICBuzilGY9nC9QIw0h2MiOZTfL2DSMWggzy6DT5WTi53LSJp4vucH5LMUw7khV.T_.keZpLr fTvu8CdfhcvXH8FuussmYpWlDw3HXIgREf_mxoEZky6Dze4.WTRGnhdzR9De8RY_GZJV306ZV_2C V9I_KW6Do.h3z.PzIXYvn2oo7URXiuZkpFbbXZAXgvzjBOSVwOD0VPjHKVxm61TOyr2NGU7RyPzF ORfcresECQPMFlTlruod_8yomfEJIrtNolopcKJhXaqIcLn8EmZKCI98onA5CVKunYOUiVYsluUC Ev89Cg1IMGW0S3Lx2p32bjcv3NteOy0NJE.R8omipuQA6H7gCiEpwYlkVXi_wdvjVjEWNsWiTcjL E3xNaDzh_tO0B.U231SF_qg__dGJeKzZTETxTbqFu2aXGv2ulthG5dW7rk_QcVmufNg_vADR.V6I 0ZORMe4ce8PpAMV9gHD_xv1ZlFkIl3vmHj7MBPVMklLorF.bMCWgxkEAHdsYN4uJ1dKZqUG.plUq tjFUf7Vi_clEnh9rw2kXYGLB0UXwFLgnNqk815HIeFiBttSzkt3Ez2i8045.afREVnNwZr5IY4Bg lYcbkwoZBmUvH1Xa5Dh8QRov2EOeiom0U7o0ojvI0J5uoEWoQgGFQHiYBrQTmx3C7pXBfO0ulSKG nxsFivhcyfO_UbbVoPaMgRw_gLY5qC9ZV_6plNPVbBimDl.bRzFhb9iQF5wPZCkpfSTQ3.bm.uX8 mv5vuRB1hDrGCVpVXpMG2LC3BsYBsVlDegbaYchmI8G9T8iuUrNcmweQRsIA9ch0ZJCWfhM5RyeZ mdSonlfD3iAhp X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Feb 2022 08:05:47 +0000 Received: by kubenode512.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0132c7e51728facae89cff915a1ba730; Thu, 03 Feb 2022 08:05:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220203015149.GA78722@www.zefox.net> Date: Thu, 3 Feb 2022 00:05:42 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> 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> <20220203015149.GA78722@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JqB7Q6f38z4ZY2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="mMs5/5On"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.44 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.941]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5202 Lines: 148 On 2022-Feb-2, at 17:51, bob prohaska wrote: > On Wed, Feb 02, 2022 at 04:18:07PM -0800, Mark Millard wrote: >> On 2022-Feb-2, at 14:32, bob prohaska 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