On Sun, Dec 5, 2021 at 12:55 PM James McCoy <james...@jamessan.com> wrote:
>
> On Sun, Dec 05, 2021 at 12:41:30PM -0500, Nathan Hartman wrote:
> > It's not dumping core on mine. I would like to debug this properly but
> > am running into various nonsense. For example, I haven't figured out
> > how to run it under gdb since svn is being called through the libtool
> > script;
>
> "libtool exec gdb ./subversion/svn ..." will run svn with the
> environment setup properly.
Perfect. That's the clue I needed. Thanks, James.
At diff_dir_added() at libsvn_client/conflicts.c:7570 (in current
trunk, r1895609) we are attempting to concat some path components
with:
copyfrom_url = apr_pstrcat(scratch_pool, b->repos_root_url, "/",
right_source->repos_relpath, SVN_VA_NULL);
However, right_source->repos_relpath is an empty string, so we end up
with b->repos_root_url plus a trailing slash, causing the path to
become non-canonical.
The fix might be as simple as checking for that and not calling
apr_pstrcat(), but I would like to dig a little more before jumping to
conclusions.
I was hoping this would give some insight to the non-canonical path
assertions we hear about every so often; I'm sure this one has bitten
before...
Cheers,
Nathan
P.S., I invoked gdb with:
$ libtool exec gdb -tui -args /path/to/subversion/svn/svn merge ^/trunk
Note: At first I thought Emacs wouldn't run it through libtool with
M-x gdb because it complained that I didn't give '-i=mi' even though I
did and displayed everything garbled; but it turns out I forgot -args:
M-x gdb -> libtool exec gdb -i=mi -args /path/to/subversion/svn/svn
merge ^/trunk
