Re: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187)

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Tue, 04 Feb 2020 11:47:15 -0800
Hi Mark,

Thanks for the heads up. r357201:has been reverted by 357522.


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.


In message <F50874A6-9998-40D2-9552-73EF8EE1DF71_at_yahoo.com>, Mark Millard 
write
s:
> 
>
> 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_free
> 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=<optimized out>, loc
> al_abspath=0x8119d2188 "/usr/src/sys/kern/sched_ule.c", wri_abspath=<optimize
> 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=<optimized out>, changed_rev=<optimized out>, ch
> anged_date=<optimized out>, changed_author=<optimized out>, checksum=<optimiz
> ed out>, dav_cache=<optimized out>, 
> >     delete_working=<optimized out>, update_actual_props=<optimized out>, ne
> w_actual_props=<optimized out>, new_iprops=<optimized out>, keep_recorded_inf
> o=<optimized out>, 
> >     insert_base_deleted=<optimized out>, conflict=<optimized out>, work_ite
> ms=<optimized out>, scratch_pool=<optimized out>) at /usr/src/contrib/subvers
> ion/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>, p
> ool=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=<op
> 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=<optimized out>, reporter=0x103d00e8 <ra_svn_reporter>, report_bato
> n=0x8116b66a8, restore_files=<optimized out>, 
> >     depth=<optimized out>, honor_depth_exclude=<optimized out>, depth_compa
> tibility_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/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=<optimi
> zed out>, 
> >     local_abspath=0x8116b4960 "/usr/src", anchor_abspath=<optimized out>, r
> evision=<optimized out>, depth=svn_depth_empty, depth_is_sticky=<optimized ou
> t>, ignore_externals=<optimized out>, 
> >     allow_unver_obstructions=<optimized out>, adds_as_modification=<optimiz
> ed out>, notify_summary=<optimized out>, ctx=<optimized out>, result_pool=<op
> timized 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=0x3ffffff
> fffffd3c8, timestamp_sleep=0x3fffffffffffd3d4, local_abspath=<optimized out>,
>  revision=<optimized out>, 
> >     depth=svn_depth_empty, depth_is_sticky=-11320, ignore_externals=<optimi
> zed out>, allow_unver_obstructions=<optimized out>, adds_as_modification=<opt
> imized out>, make_parents=<optimized out>, 
> >     innerupdate=<optimized out>, ra_session=0x8116a2240, ctx=<optimized out
> >, pool=<optimized out>) 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=<optimized out>, depth=<optimized out>, depth_
> is_sticky=<optimized out>, 
> >     ignore_externals=<optimized out>, allow_unver_obstructions=<optimized o
> ut>, 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=<optimi
> zed 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 o
> ut>, pool=0x810dc0028, exit_code=<optimized out>) at /usr/src/contrib/subvers
> ion/subversion/svn/svn.c:3247
> > #19 main (argc=<optimized out>, argv=<optimized out>) 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_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Tue Feb 04 2020 - 18:47:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC