From owner-freebsd-current@freebsd.org Tue Feb 4 16:47:16 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 F2EC222B673 for ; Tue, 4 Feb 2020 16:47:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (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 48BrFt6Mv7z47qN for ; Tue, 4 Feb 2020 16:47:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: DN840f4VM1mqja6qBy0gPO6TgduwPG_fkse1ddrRMamkGkuuKOF3ZzZIlt1fLAB QmLZgJhhghBKv2unwz7fqhipWPoFfOadbl3Qc9SiLKgEn86n6Wf9FCq0LpINhWOIXh.M.9AfFvtW zlj_gmIuHT2ZrnI0TzNFLjM_pA4MOvsL4VxtNSOnDRcSEfmkwWPoXEFXjslIAUNE000M4TI7gkcg _Xhb5h8nRMpHTX5POfyzMxQ3cCXG8.kShQUYxyMrGndrOYG8KCbtDGnlFfVzlcPCVXdg3YZfAFMU bsuc5mon3WvSROCKSVkJh4rl6Gt5CZeDQLWkhyq23ovVHRYtLM14gQqLmaTGy9CY9hf0VZGfKi6y z3RmUGC5xY7BPfeHyZVA_i4dQQx58vIwKoHECmyKG2Sn2aanPwU4hYUpaPWRw_aLx6q5GVeB9Oms Y1pjBoeXOo5VqjzFJCXQE.gdVTyXxHhGjWuf3Jb4DF13Qg5pM6gCy_hcJTN2gFeZn4HVCXN_PIoW R9y5hgZCkNaG4gth.aYcnt8xAfkOaFquUOyxJtBfmsPuq4EiJE3Cd9q_akkO0CbW24PCkWuEcucf xpFKlRVFCi8cdKJYQx5Vpb2hLTrlSTLzAKtLthNIvv_qN5vkflrouCiU6_kzNs3diW6CWkrfSeCe bt9H5GRofgxQhKP0jj4YKuY7al.kXYB450EeNYcilI9Zm82Sd2.vRP6GQ0oSSRNzo5C13bLmS.Ap ManYMsn8Mnvf9as9QOV.9Cx2wcEcoPOV03XdFM6xS_BI5Lime0CcEs2Mdtwny5mx7VmOm2T1xznA 0kApjkFS2g_b2WyeXc2Movs4.4fAkCjijhrAjeqroWbLq3JsS.yTERhldE5A41HA06DkAtt.hrQH 3zTNqKbLzV0ex9liDOa69yomwuItBDhYV2I4GNMQDjHkO4jap7bljR9YH_QBZTl5DI2JdRowN2Yc wWauupJfvHxprFVoAeYcnGGZQx1piNO8vXuD15g1VG0HJMrBph4kZr2PKBbeiVKbtf9oYol_zZ4J A0WeQqsLXRvZgsKIRMKrVnKPNXkKN77cPfhoRofuhZWPZgi1PDPZvvSHKdQigAp6ZtbmrPdb7T13 PDn.ftBSs48GSLi0wFXLMhgN3Iv6JdRClEH5FprHhqaM.fAz36RUdduyWivNg0vM._3mMDRsWIJG G2cqfD5B9tld5n_x4t1qE.qWRWYsaCTOyN5v1LvAz9Mqw7o1jQ1JpN1Xzuz6LrUe9pmt7U9Ebl.L T2lZHVNA9rG9CzzGZU_.pWPCetAiFnANoVvYEIvY70xs9JyjRwi3NegpkxjTcTrFDnUJ.iP2kRLY NTxZuaARQZ.TWgry0bbxAErE8fQBJqtJpb5epa_x_Byzx724n76EucaiHjp0_G1JAwQVC.uvREZz Zu0ELgt.bQ8et906OA3rWBowlASOCDs6IvEQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Feb 2020 16:47:11 +0000 Received: by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 82958aa0cf2e88a48fff5c48da1f9baa; Tue, 04 Feb 2020 16:47:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187) From: Mark Millard In-Reply-To: Date: Tue, 4 Feb 2020 08:47:04 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Francis Little X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48BrFt6Mv7z47qN X-Spamd-Bar: / X-Spamd-Result: default: False [-0.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.25)[-0.250,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.05)[-0.046,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[205.64.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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)[]; IP_SCORE(0.00)[ip: (4.76), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] 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 16:47:17 -0000 On 2020-Feb-4, at 00:15, Francis Little wrote: > I have the same issue on my PowerMac G5 running HEAD, svnlite = segfaults. >=20 > I have installed subversion from ports for now as a workaround. I will note that svnlite has not changed in head for some time but sql3lite (which svnlite uses as I understand) changed at -r357201 to 3.31.0 . In ports sql3lite 3.31.0 has been reverted for segmentation fault problems with firefox's use of it. (More than firerfox might have been noticed if sql3lite 3.31.0 had lasted more than 24 hours.) > Regards >=20 > On Tue, 4 Feb 2020 at 03:47, Mark Millard via freebsd-ppc = wrote: > 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.) >=20 > The report does have a backtrace towards the > end of this note. >=20 > 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: >=20 > # svnlite update -r357473 /mnt/usr/src/ > Updating '/mnt/usr/src': > At revision 357473. >=20 > (/mnt is a mount of the normal SSD that when booted > would be at head -r357419 and was intended for a > update to -r357473 .) >=20 > 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.) >=20 > 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. >=20 > 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.) >=20 > I did various retries by re-establishing the > copy with no differences found. Each time > the result was the same. >=20 > So for the above working command, I again > established the copy before switching boot > media to the head -r356187 emergency SSD. >=20 > Booted from -r356187, svnlite update > -r357473 on the tree ( now /mnt/usr/src/ ) > works fine. >=20 > 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. >=20 >=20 > FYI: I recorded a backtrace from a core that > was produced in one of the example failures > ( under head -r357419 ): >=20 > 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 >=20 > I did not look at the machine code level at all. > Nor am I familiar with svnlite internals: blind > copy. >=20 > 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)