From owner-freebsd-ppc@freebsd.org Tue Feb 4 19:47:24 2020 Return-Path: Delivered-To: freebsd-ppc@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 7B6B0231FB1; Tue, 4 Feb 2020 19:47:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48BwFl2jJnz4SPL; Tue, 4 Feb 2020 19:47:23 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id z4AHi9IOJkqGXz4AJifrZS; Tue, 04 Feb 2020 12:47:21 -0700 X-Authority-Analysis: v=2.3 cv=c/jVvi1l c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=CjxXgO3LAAAA:8 a=-s3YgSkqAAAA:8 a=IIX2BFdiAAAA:8 a=YVOhz5M6AAAA:8 a=1h5lhL6jEo75h7liBrcA:9 a=BYvsm9vmAV7P4SJ7:21 a=RoCJjrwBUASY1Hm9:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=KNVyK3WTYxrh98G-kjJX:22 a=rHg00LAlvzXsuODty-Nv:22 a=sbbTL3E6IKcx-RquDtO-:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 623B1108C; Tue, 4 Feb 2020 11:47:16 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 014JlFxK005820; Tue, 4 Feb 2020 11:47:15 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 014JlFFR005817; Tue, 4 Feb 2020 11:47:15 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202002041947.014JlFFR005817@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mark Millard cc: Francis Little , FreeBSD PowerPC ML , FreeBSD Current Subject: Re: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187) In-reply-to: References: Comments: In-reply-to Mark Millard message dated "Tue, 04 Feb 2020 08:47:04 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Feb 2020 11:47:15 -0800 X-CMAE-Envelope: MS4wfFzCVnINhsRsQSpSYQAQjBk0NgTc5X0Vq3WQBoiXDdmoUJslk+P252vAL2usgzps256QtTBkn2zNGwVEutLdGrhuHkWPTRDFUj9l4/6IzyDp0o9N7VgV JPHu+zaPBpcDl+kbas+XzT9jNwKbmWJKDDq/oDw9FIQUufnV7uOW9dKM+0wf4tk/eFoLaUY3TGrpCe+l4NcFtrnLE7v1oi1zd2RKENOYGsgGZGugZjKgEY/C JazR47W2eJJLKnluJYN65CmgCCXKrNt+Ipel+o8jvtbLs4NMaz/IkAsq1g8bxdcs X-Rspamd-Queue-Id: 48BwFl2jJnz4SPL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.12) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.18 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RWL_MAILSPIKE_GOOD(0.00)[12.134.59.64.rep.mailspike.net : 127.0.0.18]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; 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:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.48)[ip: (-6.61), ipnet: 64.59.128.0/20(-3.20), asn: 6327(-2.49), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 19:47:24 -0000 Hi Mark, Thanks for the heads up. r357201:has been reverted by 357522. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message , Mark Millard write s: > > > On 2020-Feb-4, at 00:15, Francis Little wrote: > > > I have the same issue on my PowerMac G5 running HEAD, svnlite segfaults. > > > > 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 > > > > On Tue, 4 Feb 2020 at 03:47, Mark Millard via freebsd-ppc bsd.org> 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.) > > > > 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=0x810df84b8, nKey=0, pKey=0x0, p=0x81 > 16ea448) at /usr/src/contrib/sqlite3/sqlite3.c:81283 > > #1 0x00000008104eec6c in sqlite3VdbeExec (p=0x8116ea308) at /usr/src/contr > ib/sqlite3/sqlite3.c:89367 > > #2 0x00000008104b2f84 in sqlite3Step (p=0x8116ea308) at /usr/src/contrib/s > qlite3/sqlite3.c:83195 > > #3 sqlite3_step (pStmt=0x8116ea308) at /usr/src/contrib/sqlite3/sqlite3.c: > 17724 > > #4 0x0000000010315e6c in svn_sqlite__step (got_row=0x3fffffffffffc484, stm > t=0x811a19420) at /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c > :347 > > #5 0x0000000010315fa4 in svn_sqlite__insert (row_id=0x0, stmt=0x811a19420) > at /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c:371 > > #6 0x0000000010195bd4 in insert_base_node (pibb=0x3fffffffffffc630, wcroot > =0x810dfd980, local_relpath=0x8119d2191 "sys/kern/sched_ule.c", scratch_pool= > 0x8119d2028) > > at /usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:812 > > #7 0x0000000010196688 in svn_wc__db_base_add_file (db=, loc > al_abspath=0x8119d2188 "/usr/src/sys/kern/sched_ule.c", wri_abspath= d out>, > > repos_relpath=0x8119d2228 "head/sys/kern/sched_ule.c", repos_root_url=0 > x8116b64f8 "svn://svn0.us-west.freebsd.org/base", repos_uuid=0x8116b6520 "ccf > 9f872-aa2e-dd11-9fc8-001c23d0bc1f", > > revision=357473, props=, changed_rev=, ch > anged_date=, changed_author=, checksum= ed out>, dav_cache=, > > delete_working=, update_actual_props=, ne > w_actual_props=, new_iprops=, keep_recorded_inf > o=, > > insert_base_deleted=, conflict=, work_ite > ms=, scratch_pool=) at /usr/src/contrib/subvers > ion/subversion/libsvn_wc/wc_db.c:1831 > > #8 0x00000000101ceaf0 in close_file (file_baton=0x8119d20a0, expected_md5_ > digest=, pool=) at /usr/src/contrib/subversion/ > subversion/libsvn_wc/update_editor.c:4550 > > #9 0x00000000102eafe8 in close_file (file_baton=0x811a0b0e0, text_checksum > =0x8119ec0e0 "6616ae311ef1f9fb859221cbbe98b2bd", pool=0x8119ec028) > > at /usr/src/contrib/subversion/subversion/libsvn_delta/cancel.c:254 > > #10 0x00000000102194f4 in ra_svn_handle_close_file (conn=, p > ool=0x8119ec028, params=, ds=0x3fffffffffffcb40) > > at /usr/src/contrib/subversion/subversion/libsvn_ra_svn/editorp.c:861 > > #11 0x00000000102184d0 in svn_ra_svn_drive_editor2 (conn=0x811755000, pool= > 0x8116b4868, editor=0x8116b6548, edit_baton=, aborted=0x0, for > _replay=) > > at /usr/src/contrib/subversion/subversion/libsvn_ra_svn/editorp.c:1114 > > #12 0x00000000102153f0 in ra_svn_finish_report (baton=0x8116b66a8, pool= timized out>) at /usr/src/contrib/subversion/subversion/libsvn_ra_svn/client. > c:302 > > #13 0x00000000101e297c in svn_wc_crawl_revisions5 (wc_ctx=0x810dc14f0, loca > l_abspath=, reporter=0x103d00e8 , report_bato > n=0x8116b66a8, restore_files=, > > depth=, honor_depth_exclude=, depth_compa > tibility_trick=, use_commit_times=, cancel_func > =, > > cancel_baton=, notify_func=, notify_baton > =, scratch_pool=) at /usr/src/contrib/subversio > n/subversion/libsvn_wc/adm_crawler.c:691 > > #14 0x00000000101741c8 in update_internal (result_rev=0x3fffffffffffd3c8, t > imestamp_sleep=0x3fffffffffffd3d4, conflicted_paths=0x0, ra_session_p= zed out>, > > local_abspath=0x8116b4960 "/usr/src", anchor_abspath=, r > evision=, depth=svn_depth_empty, depth_is_sticky= t>, ignore_externals=, > > allow_unver_obstructions=, adds_as_modification= ed out>, notify_summary=, ctx=, result_pool= timized out>, scratch_pool=) > > at /usr/src/contrib/subversion/subversion/libsvn_client/update.c:501 > > #15 0x0000000010173708 in svn_client__update_internal (result_rev=0x3ffffff > fffffd3c8, timestamp_sleep=0x3fffffffffffd3d4, local_abspath=, > revision=, > > depth=svn_depth_empty, depth_is_sticky=-11320, ignore_externals= zed out>, allow_unver_obstructions=, adds_as_modification= imized out>, make_parents=, > > innerupdate=, ra_session=0x8116a2240, ctx= >, pool=) at /usr/src/contrib/subversion/subversion/libsvn_cli > ent/update.c:648 > > #16 0x0000000010174518 in svn_client_update4 (result_revs=0x3fffffffffffd4f > 0, paths=0x810dfd140, revision=, depth=, depth_ > is_sticky=, > > ignore_externals=, allow_unver_obstructions= ut>, adds_as_modification=, make_parents=, ctx= > , pool=) > > at /usr/src/contrib/subversion/subversion/libsvn_client/update.c:722 > > #17 0x000000001011db9c in svn_cl__update (os=, baton= zed out>, scratch_pool=0x810dc0028) at /usr/src/contrib/subversion/subversion > /svn/update-cmd.c:169 > > #18 0x000000001011d118 in sub_main (argc=, argv= ut>, pool=0x810dc0028, exit_code=) at /usr/src/contrib/subvers > ion/subversion/svn/svn.c:3247 > > #19 main (argc=, argv=) at /usr/src/contrib/s > ubversion/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. > > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >