On Nov 16, 2007 1:10 AM, David Glasser <glasser@davidglasser.net> wrote:
>
> On Nov 16, 2007 12:08 AM, David Glasser <glasser@davidglasser.net> wrote:
> >
> > On Nov 15, 2007 11:34 PM, David Glasser <glasser@davidglasser.net> wrote:
> > > On Nov 15, 2007 11:03 PM, David Glasser <glasser@davidglasser.net> wrote:
> > > > On Nov 15, 2007 11:00 PM, David Glasser <glasser@davidglasser.net> wrote:
> > > > > On Nov 15, 2007 1:54 PM, Jeremy Whitlock <jcscoobyrs@gmail.com> wrote:
> > > > > > > I'm working on the node-origin cache now, but somebody could
> > > > > > > investigate this...
> > > > > >
> > > > > > I'll look into it.
> > > > >
> > > > > I saw on IRC that you were tracking it down; where is the crash?
> > > >
> > > > Ah, now I see that on IRC too; you said it was in
> > > > libsvn_client/copy.c(path_relative_to_session) at the call to
> > > > svn_path_uri_decode. It appears that path_relative_to_session is
> > > > called with a full_url that is not actually a child of the session
> > > > URL. This code is from cmpilato's r27728 RA cleanup.
> > >
> > > gdb shows that the actual session URL in the RA struct is corrupt!
> > > "svn://127.0.0.1/svn-test-work/repositori@峢 㜀∀
> >
> > OK, I found the line where the session URL is being overwritten, but
> > it's not too relevant... the problem is that the pool is cleared
> > somewhere.
>
> cmpilato figured it out! Here is the relevant backtrace
>
> #0 ra_svn_reparent (ra_session=0x7e35b0, url=0x7f2bd0
> "svn://127.0.0.1/svn-test-work/repositories/copy_tests-58/A/D/H/chi",
> pool=0xfb018) at subversion/libsvn_ra_svn/client.c:669
> #1 0x00085eaf in svn_ra_reparent (session=0x7e35b0, url=0x7f2bd0
> "svn://127.0.0.1/svn-test-work/repositories/copy_tests-58/A/D/H/chi",
> pool=0xfb018) at subversion/libsvn_ra/ra_loader.c:510
> #2 0x00211b26 in get_implied_mergeinfo (ra_session=0x7e35b0,
> implied_mergeinfo=0xbffff014, path=0x7f2b88 "D/H/chi", rev=2,
> ctx=0x180bed0, pool=0xfb018) at subversion/libsvn_client/copy.c:102
> #3 0x00211d89 in calculate_target_mergeinfo (ra_session=0x7e35b0,
> target_mergeinfo=0xbffff014, adm_access=0x0, src_path_or_url=0x7e33e0
> "svn://127.0.0.1/svn-test-work/repositories/copy_tests-58/A/D/H/chi",
> src_revnum=2, ctx=0x180bed0, pool=0xfb018) at
> subversion/libsvn_client/copy.c:173
> #4 0x00215445 in repos_to_wc_copy_single (pair=0x7e3078,
> same_repositories=1, ra_session=0x7e35b0, adm_access=0x7e45b8,
> ctx=0x180bed0, pool=0xfb018) at subversion/libsvn_client/copy.c:1507
> #5 0x00215d93 in repos_to_wc_copy (copy_pairs=0x7e3050,
> make_parents=0, ctx=0x180bed0, pool=0x7e3018) at
> subversion/libsvn_client/copy.c:1717
> #6 0x002167e3 in setup_copy (commit_info_p=0xbffff29c,
> sources=0x18116a0, dst_path_in=0x1811668
> "svn-test-work/working_copies/copy_tests-58/A/C", is_move=0, force=1,
> make_parents=0, with_merge_history=0, ctx=0x180bed0, pool=0x7e3018) at
> subversion/libsvn_client/copy.c:1988
> #7 0x0021690c in svn_client_copy4 (commit_info_p=0xbffff2f4,
> sources=0x18116a0, dst_path=0x1811668
> "svn-test-work/working_copies/copy_tests-58/A/C", copy_as_child=1,
> make_parents=0, with_merge_history=0, ctx=0x180bed0, pool=0x180b418)
> at subversion/libsvn_client/copy.c:2020
> #8 0x00005e09 in svn_cl__copy (os=0x180b550, baton=0xbffff44c,
> pool=0x180b418) at subversion/svn/copy-cmd.c:135
> #9 0x0000d945 in main (argc=14, argv=0xbffff620) at subversion/svn/main.c:1825
>
> Specifically, the pool in ra_svn_reparent is a pool little iterpool in
> repos_to_wc_copy...
r27850.
I am amused that the two bugs I fixed today were an enormous memleak
and a crasher, whose solutions were "use the temporary pool, not the
one on the data structure" and "use the pool on the data structure,
not the temporary one" respectively :)
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
Received on Fri Nov 16 10:27:39 2007