Date: Mon, 3 Feb 2020 19:46:47 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187) Message-ID: <B5EAEE6A-73B0-4BFD-B4D6-879835D195BB@yahoo.com> References: <B5EAEE6A-73B0-4BFD-B4D6-879835D195BB.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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<optimized =
out>, local_abspath=3D0x8119d2188 "/usr/src/sys/kern/sched_ule.c", =
wri_abspath=3D<optimized out>,=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<optimized out>, changed_rev=3D<optimized =
out>, changed_date=3D<optimized out>, changed_author=3D<optimized out>, =
checksum=3D<optimized out>, dav_cache=3D<optimized out>,=20
delete_working=3D<optimized out>, update_actual_props=3D<optimized =
out>, new_actual_props=3D<optimized out>, new_iprops=3D<optimized out>, =
keep_recorded_info=3D<optimized out>,=20
insert_base_deleted=3D<optimized out>, conflict=3D<optimized out>, =
work_items=3D<optimized out>, scratch_pool=3D<optimized out>) at =
/usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:1831
#8 0x00000000101ceaf0 in close_file (file_baton=3D0x8119d20a0, =
expected_md5_digest=3D<optimized out>, pool=3D<optimized out>) 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<optimized =
out>, pool=3D0x8119ec028, params=3D<optimized out>, =
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<optimized out>, =
aborted=3D0x0, for_replay=3D<optimized out>)
at =
/usr/src/contrib/subversion/subversion/libsvn_ra_svn/editorp.c:1114
#12 0x00000000102153f0 in ra_svn_finish_report (baton=3D0x8116b66a8, =
pool=3D<optimized out>) 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<optimized out>, reporter=3D0x103d00e8 =
<ra_svn_reporter>, report_baton=3D0x8116b66a8, restore_files=3D<optimized =
out>,=20
depth=3D<optimized out>, honor_depth_exclude=3D<optimized out>, =
depth_compatibility_trick=3D<optimized out>, use_commit_times=3D<optimized=
out>, cancel_func=3D<optimized out>,=20
cancel_baton=3D<optimized out>, notify_func=3D<optimized out>, =
notify_baton=3D<optimized out>, scratch_pool=3D<optimized out>) 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<optimized out>,=20
local_abspath=3D0x8116b4960 "/usr/src", anchor_abspath=3D<optimized =
out>, revision=3D<optimized out>, depth=3Dsvn_depth_empty, =
depth_is_sticky=3D<optimized out>, ignore_externals=3D<optimized out>,=20=
allow_unver_obstructions=3D<optimized out>, =
adds_as_modification=3D<optimized out>, notify_summary=3D<optimized =
out>, ctx=3D<optimized out>, result_pool=3D<optimized out>, =
scratch_pool=3D<optimized out>)
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<optimized out>, revision=3D<optimized out>,=20
depth=3Dsvn_depth_empty, depth_is_sticky=3D-11320, =
ignore_externals=3D<optimized out>, allow_unver_obstructions=3D<optimized =
out>, adds_as_modification=3D<optimized out>, make_parents=3D<optimized =
out>,=20
innerupdate=3D<optimized out>, ra_session=3D0x8116a2240, =
ctx=3D<optimized out>, pool=3D<optimized out>) at =
/usr/src/contrib/subversion/subversion/libsvn_client/update.c:648
#16 0x0000000010174518 in svn_client_update4 =
(result_revs=3D0x3fffffffffffd4f0, paths=3D0x810dfd140, =
revision=3D<optimized out>, depth=3D<optimized out>, =
depth_is_sticky=3D<optimized out>,=20
ignore_externals=3D<optimized out>, =
allow_unver_obstructions=3D<optimized out>, =
adds_as_modification=3D<optimized out>, make_parents=3D<optimized out>, =
ctx=3D<optimized out>, pool=3D<optimized out>)
at /usr/src/contrib/subversion/subversion/libsvn_client/update.c:722
#17 0x000000001011db9c in svn_cl__update (os=3D<optimized out>, =
baton=3D<optimized out>, scratch_pool=3D0x810dc0028) at =
/usr/src/contrib/subversion/subversion/svn/update-cmd.c:169
#18 0x000000001011d118 in sub_main (argc=3D<optimized out>, =
argv=3D<optimized out>, pool=3D0x810dc0028, exit_code=3D<optimized out>) =
at /usr/src/contrib/subversion/subversion/svn/svn.c:3247
#19 main (argc=3D<optimized out>, argv=3D<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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B5EAEE6A-73B0-4BFD-B4D6-879835D195BB>