On 2020-Feb-4, at 00:15, Francis Little <oggy_at_farscape.co.uk> 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 <freebsd-ppc_at_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)Received on Tue Feb 04 2020 - 15:47:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC