From nobody Thu Feb 3 17:17:06 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 B936C19AB5FE for ; Thu, 3 Feb 2022 17:17:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4JqQMd4ZpKz3HgK for ; Thu, 3 Feb 2022 17:17:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643908630; bh=Oj5NkX73fOkLeaCYnXFzIpfVumNBTwyfWinXhgqVXmg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=K+Nc8Wid5V6j50CFAhntW4Gh/GWV6ZhMTEeBQVUAobI8EX2v8wkmNN6ednQP8zioktCK9KruiUbw3xl32IVqbeslctQL/+T70gXhqc6QhklmMjM9Qg87BDrdxnk40IqAPCt9Z0RUuU4TQ+UsgX2jSZFSzlewsym/oj09kc7OdH9Pjk/2SnH7J9xuXZqoU2nDHR7jQdnKywaRV5hCfB57+ngJKxKvtUqpWqljCamzPxfQ9Y9aTWIT3+08jQw1LmbofuK6ymSsEg3bhKBDZDAECprBDmSc/praiYufRVHWHMjtrb6b1kFndiaDw6p1NQ+HJu/dNDvYEnj9+YASpKopog== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643908630; bh=qRQboE/DJwmck9OHfyr3ctC2VdXdHPWhrj3hjDAl5uB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sMSu+gCDbFX10EvWxiMvUFBCjh3tCW+L8S7+KJ8vmhEXJKOyP+1f+E00cCSgDnWhk3SQveZ85umFtYOfsUSDQGzTlLJOC2NSyWXDFCho8Xupf9oTodntH4ReUiGL/MNNEkEN2PYq7V+iIOSYYjbEciCUAJfiFac9ehYPPzPb2C1ZcBGsrfu1Wo1SItmZb4X6nZ9RbXLRBpbBOEi0sRiQOdJDXANph5Nuwr3DpopLbsiMPdi4V6OUC3waddO5xc4vz4a+lJpa4afj30Q4rgj9nJHbczixl/sKpNK3Lz1ePzUBL+VjdBZsK61eG8nX9LnvKH34345Ri4iDbYraykiKAQ== X-YMail-OSG: iApgMhQVM1m9tYEwPK6VfWLZxA9SY2ygxiQxfFuR.rrvKMLTvdUQ248xMRzxhgl keMZJCg5zi9cYZdsuELCXM2_q5tGWIv4WfBVREtWfMHt1pqhBYtQSuth2S.ZY5eDzCHSHj6SRHpM u6ttimr9H9nFlF0ug5hxjM4kTbCafzhQoHz3V0qwyouPBSp_OoSGfMbhfNTaJqgCc9unS9EPtOJU AOzC0Aym5MzlPtcOGOo7Qo2F0Vj1QzZEuRsl0dNnA3565DlLCDqEIR.ueRCd3jJa3geP5_nNisGh lVNZMIy3iyP8_K6d.fUqWorFKX8hUG_7XO6EUaC_34z.75eIGNzsJ3HysssF5h11b__1FlDyQkI0 0hDXt.BCemx86x0XZpbDMqnXF0hQpECLO0_bTY_q4JgxJglTKdSeDeN2c_acjGPC8rmyZ6MqMEys zSmfmVELLpqm74_ffmouIq.xSnCuJsbn6iL_K4uke8Wtjn14lG7gIrJ9NpqtFPNivuBxbLZAi8Kx 8WvTf5BDX4VTUqEGQjdg0IfUcNOag4IJcl.qRbX9kUTEN9NJDYOEB29YCikFx5th9kEzgG4Rx2Q4 RYdia2H.JvTzpj_m8hfGmVlG90nZJaIvgtRWQu.DiOfOngLA0efMdctlpAP.H2jWS6XVx8eLfv43 q2Jgch6y.TIzmDU2BIZ8kwjRm4nY0XDLTjO4jU1UTT45L7fpdEiuB3CFCJdhC7YvLm4y5fQlPqhv iemd8yxE1V3oI2yM5FvMgA0dpC3YzcUdfRLp81JYB3svqJHd27FPpQV.ANhQSv2tjPTRfuBroogZ xFwKYMi0tk45XSESfRNq2SmkM7O3rdm21RT07Y.MeWvYj5RzE96By3pIf43A3.Z.PuNGHaa8FfcH .oP_DZxSvoGdIzRP15TOfP1PuNjGjzr1ykgINEhPrJjF5DUYPfbz41Yv1ZKzeftX6nbvpOGy11BC lTWy1RDBjC6.u6KQrsVawc5DWlbXwGgV99SsFYHKBs3sCOj2CafebN_4snU6rlMolSQ8U5WELmeS _ju0f5T.LMOF3i1FpBHSJJgUqU.m74kAGUTF5SQuXC4ZjdEUKpz7x4wHanqCCdh8OAWO.95xxLEV VP1cPbG1vfNCia26bKpUNhSqxtHrEHiqUbzWdf_d.gVNpf3.3QQqczDTKU9QV_sDxEyT5TcFHHBP zyWin9iytNgi5v1zRoD5cNQFuVexWimzPXkWHRu7lg3tcecUVdlDDLpqzwjlZXvYUbO.CH7kI2zX r5urlWEZ1EYS8yzfvDiLwz4m9G5rKA0Zuzl3ujJivsvaP49GFfgSeTOng_xALzGvzkrK.JcWQ52g mYlBAWfaktncve3m.9DS3erN4Crl4iVLyRFs9fZqscFOJfr3MWu788bke89jnreqUZnsGBRVfj93 _Cvx8iDub1Y..pUYK1I2C67Zt1jEe4GKDo_ZzuGV_5IT4h3hYpvcv8PzFkFyPgz8srhitDTUvlgN nyKuEhZMAkR_nG4nh4jQaP8kB4OLX6rddmaEbIOtgeIzfRrnVWVxywifqX13gaYcFutRcYqwGa3I .Ym4Hdhsp88rioB4IKZRbk38Zu7ENzKfGwliqi5zjn297A6lfemyocCvT5wewcdYvH_qhvi0B_RV TVarHgKbi.EOlvrNbt2.Z7dcsTjmVrQEz.zWY_pKbznxZSUDKGGkCgAzsY8YmJ9FoArebWuE6dTp TZXghQ3LxWk72v.fluIe7jHAFVif6VziXlF7hOmDwWkXTMxjT.Fn68VdUugBPqsD1s4xUi4Apxpb 1h.MvILHQqsJGCFkt9CrqDSn99ux3iZn53DPpvebZXXQWw7fYJfOMYIFH86Vn_sat3MbI2nEk9mC nAAQvUOr_hqDlQiYE8p_noe6kLHBSEj0tsHFz3na_4JvRzBWXTph1YDECmQwEp24SV44f2V40Yz. BLwzwnvbGeKg_bGEmNmwnJvBIa0yhNSJ_x5w5UwDGYOcjkpiwRzBZqt3snZfsMKYNrAPNBo6VX73 SiRmZSNeCsFLdusgcbgcAJIzugArGJya8NE9HfTujk2iGmVSgw.lPGuXfUR.u5sg43Zi59zYJ5ih yyyfbrSIqXWOosGGewagUmNQ0noLPWpGAYjB_M9kRUCkaZZLFlS32BPNfGUPHLv0c6U_NXTrnZ3D L3et.PEvkI8fE1rhkipoCfa9kC.ePUbH_JsRlpaCVdBBiKHLaV7jGHw0tycdAr2M7V01xQ14.5Pe qfzw_3IuZ.E_wJ.c3Az31u09uW273Koka2WcIkmXaZt3g5ocvx0Bin10etki.zYTgkS_S9ei4N.a uzPdXbsVwOx0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Feb 2022 17:17:10 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cc5ba7bccb206c0e551ee531618cbead; Thu, 03 Feb 2022 17:17:07 +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: <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> Date: Thu, 3 Feb 2022 09:17:06 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JqQMd4ZpKz3HgK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=K+Nc8Wid; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.45 / 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(-0.95)[-0.949]; 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(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5596 Lines: 157 On 2022-Feb-3, at 00:05, Mark Millard wrote: > On 2022-Feb-2, at 17:51, bob prohaska wrote: >=20 >> 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 . >=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