From owner-freebsd-current@freebsd.org Tue Feb 4 03:46:54 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6F5A723A36F for ; Tue, 4 Feb 2020 03:46:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 48BVxT3Qqmz4b2f for ; Tue, 4 Feb 2020 03:46:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: q4J6pqAVM1n6i6MerpmEZAUDGv9rbGjM3iRs820DNtgnGSwofqiCDWsrVD0UZqL 1TiMfdjmPrURm5kuvMOpBK83vZbs8LZsODdRlY5R1trfYjVO3Ez_PlUXI23C6l_jJGQQLxR6miw9 ujekt.OHpRvI.KL3lm5CvpCmgsSIdQw6y39MiRMIKCy7X9_cucvZBVLwQqZ.GEbMxQdFZ_pgeP3o 4w4cKlEY_59ehoyJDeGEom6RaLstn5.uZvQ1aZxM.c_4ZeZcnvRiYtPk7LVN5Iz9hKi4f1JT73.Z xnemM9NS0HqqQl9T5wgsJHTByz0b4fT50XfzddWcxRlEbal96vZckpzGvfU1LWMn5naU6oBmBPC. TIxXFwhMJvpCtAhMR_eco.oq5qAYyLDK4OkAimvFFzCcfPZD.0fFg90uvlalRLOl8PWX196WnLRV uedpbXahmh2c6JFs.msYi7Y7_gwv8j5ugX.nSukfrWHkXmXXvtq18IY_rjAs1pO0KqE1sqk.tStr ycU3Yd4Nks4C6..8c.1eJlm2fS1868qy_lOgiH1GT06d9MWQA2c3o_kOajr0kesD4NnrCpU_jN8s u.ScM83mG.1T5tsB6_nivPocdfb2ExmdhnwbvVRYQrdVhMrB11zRRcFV69ZDEvYkV6cLM4T_KSUQ wm6PShSYU7fkBbFqeXbE9UbshRv0hgX8F4hub5OJcYJcBc5PVoUmFIWLZXey61JhIZdQYqFfu8PO MbIs4Sj5yJycwZ5gIW4zbeeH5ucVu1GemtYS7R2udKaDJFcK78vwlvt7EdVh9LdV1iii.wzaB.II H8b2agpEkRQ2Gwm5xY7Eogbfsmm4aWuctQBPP4_0yTAVF.FNfmB4mQADj9JDU6CFtlUH9d8Hx2nW V4NmVKc3dcOChJS7erdbMzG9P3qYpUOqNGr2a.Tu7CFCFmTzxQ7s8yQdgHllH7vAIgX9ppUtV1Y. 82hc7zvv_o44T.Gw9Ju6JWsC7rA54_v.Zj9tWJQGMzj_v8U7wfRoZtUUPTyfA1N_Z0MQbpFQqo4H wOPlTJMDmdz4ms5djxJIUcR4tMo8xovIrep01_xPMbzWf_j13vA4ORRcKWr6ftbA13XCbwh7ylN0 EGgFIU.nXP6a_Z2IqEwNMGT0ErwJpqxxwBGcFYOFGhDBLWHuqQoE.rdbTT5Ji0aXBVLrM93PHAEo kA3ArhdcwkcPnWPV855Udw.bQsSvC18Mym8Zrafw2rV.KxiUdW.hc24c2kOf2I1PEuWOACGebyqx OxNDA0sADhZ_DpKNwnISjXK06vdumrIKBxHMo7ZBVTACV9BYsM79oO31WXyFA_nWwaYqt01QaLn1 4TKA26lvlHxHDY._G5V3ka6a.DtXrzvQmVQDsMepd3EJUrSrIpQf4oyHk005S1BlpWi9QF98Jk0X rpB2uKgo5.ludWHww4cXwQ55C4OrDqDoah_Q11iDnq_NIDHZVMrhHnKBHnmVitZAhDzCr8g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Feb 2020 03:46:52 +0000 Received: by smtp413.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e82e4b94883d412ca484c9b1c01cde78; Tue, 04 Feb 2020 03:46:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187) Message-Id: Date: Mon, 3 Feb 2020 19:46:47 -0800 To: FreeBSD PowerPC ML , FreeBSD Current X-Mailer: Apple Mail (2.3608.60.0.2.5) References: X-Rspamd-Queue-Id: 48BVxT3Qqmz4b2f X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.38 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.893,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.988,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (0.85), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[32.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[32.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 03:46:54 -0000 Given various issues that have been going on, I offer the following as a possible evidence for a problem still existing for powerpc64 as of head -r357419. Unfortunately, I do not have the time or context to do much for tracking it down. (I've already spent time on other unexpected failures in recent times.) The report does have a backtrace towards the end of this note. I have reverted to booting an emergency SSD that is at head -r356187 in order to have the following work instead of getting a segmentation fault on the old PowerMac: # svnlite update -r357473 /mnt/usr/src/ Updating '/mnt/usr/src': At revision 357473. (/mnt is a mount of the normal SSD that when booted would be at head -r357419 and was intended for a update to -r357473 .) Under head -r357419 on the G5 PowerMac, such a command ( then /usr/src/ ) gets a segmentation fault instead. (svnlite cleanup then leaves things corrupted as well.) This started by an attempt to update /usr/src/ from -r357419 or -r357473 . The -r357419 had been established via snvlite update under -r356426 and that had no problems. But this update under -r357419 just segmentation faulted. After discovering that I could not update the source tree natively, I copied over a -r357473 /usr/src/ from elsewhere and checked it with diff -r and rsync. I then tried to see if it would do like the above but it again segmentation faulted instead. (No actual source update needed, so a simpler case.) I did various retries by re-establishing the copy with no differences found. Each time the result was the same. So for the above working command, I again established the copy before switching boot media to the head -r356187 emergency SSD. Booted from -r356187, svnlite update -r357473 on the tree ( now /mnt/usr/src/ ) works fine. As another experiment, before switching to -r356187 , I swapped to a head -r356426 kernel copy and got the same sort of failing result. But that was mixing a 1300075 kernel with a 1300076 world, if I remember the numbers right. Still, since -r356426 for both kernel and world together updated to -r357419 okay, it may suggest that the more recent world contributes to or causes the failure instead of it being (just?) a kernel problem. FYI: I recorded a backtrace from a core that was produced in one of the example failures ( under head -r357419 ): Program terminated with signal SIGSEGV, Segmentation fault. . . . (gdb) bt #0 sqlite3VdbeRecordUnpack (pKeyInfo=3D0x810df84b8, nKey=3D0, pKey=3D0x0,= p=3D0x8116ea448) at /usr/src/contrib/sqlite3/sqlite3.c:81283 #1 0x00000008104eec6c in sqlite3VdbeExec (p=3D0x8116ea308) at = /usr/src/contrib/sqlite3/sqlite3.c:89367 #2 0x00000008104b2f84 in sqlite3Step (p=3D0x8116ea308) at = /usr/src/contrib/sqlite3/sqlite3.c:83195 #3 sqlite3_step (pStmt=3D0x8116ea308) at = /usr/src/contrib/sqlite3/sqlite3.c:17724 #4 0x0000000010315e6c in svn_sqlite__step (got_row=3D0x3fffffffffffc484, = stmt=3D0x811a19420) at = /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c:347 #5 0x0000000010315fa4 in svn_sqlite__insert (row_id=3D0x0, = stmt=3D0x811a19420) at = /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c:371 #6 0x0000000010195bd4 in insert_base_node (pibb=3D0x3fffffffffffc630, = wcroot=3D0x810dfd980, local_relpath=3D0x8119d2191 = "sys/kern/sched_ule.c", scratch_pool=3D0x8119d2028) at /usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:812 #7 0x0000000010196688 in svn_wc__db_base_add_file (db=3D, local_abspath=3D0x8119d2188 "/usr/src/sys/kern/sched_ule.c", = wri_abspath=3D,=20 repos_relpath=3D0x8119d2228 "head/sys/kern/sched_ule.c", = repos_root_url=3D0x8116b64f8 "svn://svn0.us-west.freebsd.org/base", = repos_uuid=3D0x8116b6520 "ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f",=20 revision=3D357473, props=3D, changed_rev=3D, changed_date=3D, changed_author=3D, = checksum=3D, dav_cache=3D,=20 delete_working=3D, update_actual_props=3D, new_actual_props=3D, new_iprops=3D, = keep_recorded_info=3D,=20 insert_base_deleted=3D, conflict=3D, = work_items=3D, scratch_pool=3D) at = /usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:1831 #8 0x00000000101ceaf0 in close_file (file_baton=3D0x8119d20a0, = expected_md5_digest=3D, pool=3D) at = /usr/src/contrib/subversion/subversion/libsvn_wc/update_editor.c:4550 #9 0x00000000102eafe8 in close_file (file_baton=3D0x811a0b0e0, = text_checksum=3D0x8119ec0e0 "6616ae311ef1f9fb859221cbbe98b2bd", = pool=3D0x8119ec028) at /usr/src/contrib/subversion/subversion/libsvn_delta/cancel.c:254 #10 0x00000000102194f4 in ra_svn_handle_close_file (conn=3D, pool=3D0x8119ec028, params=3D, = ds=3D0x3fffffffffffcb40) at = /usr/src/contrib/subversion/subversion/libsvn_ra_svn/editorp.c:861 #11 0x00000000102184d0 in svn_ra_svn_drive_editor2 (conn=3D0x811755000, = pool=3D0x8116b4868, editor=3D0x8116b6548, edit_baton=3D, = aborted=3D0x0, for_replay=3D) at = /usr/src/contrib/subversion/subversion/libsvn_ra_svn/editorp.c:1114 #12 0x00000000102153f0 in ra_svn_finish_report (baton=3D0x8116b66a8, = pool=3D) at = /usr/src/contrib/subversion/subversion/libsvn_ra_svn/client.c:302 #13 0x00000000101e297c in svn_wc_crawl_revisions5 (wc_ctx=3D0x810dc14f0, = local_abspath=3D, reporter=3D0x103d00e8 = , report_baton=3D0x8116b66a8, restore_files=3D,=20 depth=3D, honor_depth_exclude=3D, = depth_compatibility_trick=3D, use_commit_times=3D, cancel_func=3D,=20 cancel_baton=3D, notify_func=3D, = notify_baton=3D, scratch_pool=3D) at = /usr/src/contrib/subversion/subversion/libsvn_wc/adm_crawler.c:691 #14 0x00000000101741c8 in update_internal = (result_rev=3D0x3fffffffffffd3c8, timestamp_sleep=3D0x3fffffffffffd3d4, = conflicted_paths=3D0x0, ra_session_p=3D,=20 local_abspath=3D0x8116b4960 "/usr/src", anchor_abspath=3D, revision=3D, depth=3Dsvn_depth_empty, = depth_is_sticky=3D, ignore_externals=3D,=20= allow_unver_obstructions=3D, = adds_as_modification=3D, notify_summary=3D, ctx=3D, result_pool=3D, = scratch_pool=3D) at /usr/src/contrib/subversion/subversion/libsvn_client/update.c:501 #15 0x0000000010173708 in svn_client__update_internal = (result_rev=3D0x3fffffffffffd3c8, timestamp_sleep=3D0x3fffffffffffd3d4, = local_abspath=3D, revision=3D,=20 depth=3Dsvn_depth_empty, depth_is_sticky=3D-11320, = ignore_externals=3D, allow_unver_obstructions=3D, adds_as_modification=3D, make_parents=3D,=20 innerupdate=3D, ra_session=3D0x8116a2240, = ctx=3D, pool=3D) at = /usr/src/contrib/subversion/subversion/libsvn_client/update.c:648 #16 0x0000000010174518 in svn_client_update4 = (result_revs=3D0x3fffffffffffd4f0, paths=3D0x810dfd140, = revision=3D, depth=3D, = depth_is_sticky=3D,=20 ignore_externals=3D, = allow_unver_obstructions=3D, = adds_as_modification=3D, make_parents=3D, = ctx=3D, pool=3D) at /usr/src/contrib/subversion/subversion/libsvn_client/update.c:722 #17 0x000000001011db9c in svn_cl__update (os=3D, = baton=3D, scratch_pool=3D0x810dc0028) at = /usr/src/contrib/subversion/subversion/svn/update-cmd.c:169 #18 0x000000001011d118 in sub_main (argc=3D, = argv=3D, pool=3D0x810dc0028, exit_code=3D) = at /usr/src/contrib/subversion/subversion/svn/svn.c:3247 #19 main (argc=3D, argv=3D) at = /usr/src/contrib/subversion/subversion/svn/svn.c:3332 I did not look at the machine code level at all. Nor am I familiar with svnlite internals: blind copy. I originally built world and kernel non-debug but with debug information. That can contribute to interpreting the backtrace. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)