Date: Tue, 4 Feb 2020 08:15:40 +0000 From: Francis Little <oggy@farscape.co.uk> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187) Message-ID: <CAGSRtz7tvoMhVzCp2gdvpKSxS36jyAp%2BXZ8YWQ2NheyXo4hf3A@mail.gmail.com> In-Reply-To: <B5EAEE6A-73B0-4BFD-B4D6-879835D195BB@yahoo.com> References: <B5EAEE6A-73B0-4BFD-B4D6-879835D195BB.ref@yahoo.com> <B5EAEE6A-73B0-4BFD-B4D6-879835D195BB@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I have the same issue on my PowerMac G5 running HEAD, svnlite segfaults. I have installed subversion from ports for now as a workaround. Regards On Tue, 4 Feb 2020 at 03:47, Mark Millard via freebsd-ppc < freebsd-ppc@freebsd.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=0x8116ea448) at /usr/src/contrib/sqlite3/sqlite3.c:81283 > #1 0x00000008104eec6c in sqlite3VdbeExec (p=0x8116ea308) at > /usr/src/contrib/sqlite3/sqlite3.c:89367 > #2 0x00000008104b2f84 in sqlite3Step (p=0x8116ea308) at > /usr/src/contrib/sqlite3/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, > stmt=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=<optimized out>, > local_abspath=0x8119d2188 "/usr/src/sys/kern/sched_ule.c", > wri_abspath=<optimized out>, > repos_relpath=0x8119d2228 "head/sys/kern/sched_ule.c", > repos_root_url=0x8116b64f8 "svn://svn0.us-west.freebsd.org/base", > repos_uuid=0x8116b6520 "ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f", > revision=357473, props=<optimized out>, changed_rev=<optimized out>, > changed_date=<optimized out>, changed_author=<optimized out>, > checksum=<optimized out>, dav_cache=<optimized out>, > delete_working=<optimized out>, update_actual_props=<optimized out>, > new_actual_props=<optimized out>, new_iprops=<optimized out>, > keep_recorded_info=<optimized out>, > insert_base_deleted=<optimized out>, conflict=<optimized out>, > work_items=<optimized out>, scratch_pool=<optimized out>) at > /usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:1831 > #8 0x00000000101ceaf0 in close_file (file_baton=0x8119d20a0, > expected_md5_digest=<optimized out>, pool=<optimized out>) 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=<optimized out>, > pool=0x8119ec028, params=<optimized out>, 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=<optimized out>, > aborted=0x0, for_replay=<optimized out>) > at /usr/src/contrib/subversion/subversion/libsvn_ra_svn/editorp.c:1114 > #12 0x00000000102153f0 in ra_svn_finish_report (baton=0x8116b66a8, > pool=<optimized out>) at > /usr/src/contrib/subversion/subversion/libsvn_ra_svn/client.c:302 > #13 0x00000000101e297c in svn_wc_crawl_revisions5 (wc_ctx=0x810dc14f0, > local_abspath=<optimized out>, reporter=0x103d00e8 <ra_svn_reporter>, > report_baton=0x8116b66a8, restore_files=<optimized out>, > depth=<optimized out>, honor_depth_exclude=<optimized out>, > depth_compatibility_trick=<optimized out>, use_commit_times=<optimized > out>, cancel_func=<optimized out>, > cancel_baton=<optimized out>, notify_func=<optimized out>, > notify_baton=<optimized out>, scratch_pool=<optimized out>) at > /usr/src/contrib/subversion/subversion/libsvn_wc/adm_crawler.c:691 > #14 0x00000000101741c8 in update_internal (result_rev=0x3fffffffffffd3c8, > timestamp_sleep=0x3fffffffffffd3d4, conflicted_paths=0x0, > ra_session_p=<optimized out>, > local_abspath=0x8116b4960 "/usr/src", anchor_abspath=<optimized out>, > revision=<optimized out>, depth=svn_depth_empty, depth_is_sticky=<optimized > out>, ignore_externals=<optimized out>, > allow_unver_obstructions=<optimized out>, > adds_as_modification=<optimized out>, notify_summary=<optimized out>, > ctx=<optimized out>, result_pool=<optimized out>, scratch_pool=<optimized > out>) > at /usr/src/contrib/subversion/subversion/libsvn_client/update.c:501 > #15 0x0000000010173708 in svn_client__update_internal > (result_rev=0x3fffffffffffd3c8, timestamp_sleep=0x3fffffffffffd3d4, > local_abspath=<optimized out>, revision=<optimized out>, > depth=svn_depth_empty, depth_is_sticky=-11320, > ignore_externals=<optimized out>, allow_unver_obstructions=<optimized out>, > adds_as_modification=<optimized out>, make_parents=<optimized out>, > innerupdate=<optimized out>, ra_session=0x8116a2240, ctx=<optimized > out>, pool=<optimized out>) at > /usr/src/contrib/subversion/subversion/libsvn_client/update.c:648 > #16 0x0000000010174518 in svn_client_update4 > (result_revs=0x3fffffffffffd4f0, paths=0x810dfd140, revision=<optimized > out>, depth=<optimized out>, depth_is_sticky=<optimized out>, > ignore_externals=<optimized out>, allow_unver_obstructions=<optimized > out>, adds_as_modification=<optimized out>, make_parents=<optimized out>, > ctx=<optimized out>, pool=<optimized out>) > at /usr/src/contrib/subversion/subversion/libsvn_client/update.c:722 > #17 0x000000001011db9c in svn_cl__update (os=<optimized out>, > baton=<optimized out>, scratch_pool=0x810dc0028) at > /usr/src/contrib/subversion/subversion/svn/update-cmd.c:169 > #18 0x000000001011d118 in sub_main (argc=<optimized out>, argv=<optimized > out>, pool=0x810dc0028, exit_code=<optimized out>) at > /usr/src/contrib/subversion/subversion/svn/svn.c:3247 > #19 main (argc=<optimized out>, argv=<optimized out>) 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. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGSRtz7tvoMhVzCp2gdvpKSxS36jyAp%2BXZ8YWQ2NheyXo4hf3A>