You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2007/10/30 17:48:02 UTC
SEGFAULT in 'svn pget' (no time to diagnose)
Ouch.
$ svn pget svn:mergeinfo .@BASE
svn: subversion/libsvn_subr/path.c:119: svn_path_join: Assertion
`is_canonical(base, blen)' failed.
Aborted (core dumped)
I remember seeing something about svn_opt_parse_path() not canonicalizing
paths any more, or somesuch. Perhaps that's to blame here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SEGFAULT in 'svn pget' (no time to diagnose)
Posted by Blair Zajac <bl...@orcaware.com>.
C. Michael Pilato wrote:
> Blair Zajac wrote:
>> Is it safe to do that, given that paths are run through these steps?
>> Are there any UTF-8 issues I need to be aware of, in the following
>> Python pseudo code?
>>
>> (peg_rev, path) = svn_opt_parse_path(path)
>> path = svn_path_cstring_from_utf8(path)
>> path = apr_filepath_merge(path)
>> path = svn_path_cstring_to_utf8(path)
>> path = svn_path_canonicalize(path)
>> path = "%s@%s" % (path, peg_rev)
>
> Well, that last step would of course not re-add a peg-rev if there wasn't
> one to begin with, but other than that, I don't know of any issues with this
> path handling plan. Where in all this does conversion to internal style
> occur? Inside svn_opt_parse_path()?
svn_opt_parse_path() doesn't call svn_path_internal_style() and neither does
svn_opt_args_to_target_array2().
By the way, the above psuedo-code for svn_opt_args_to_target_array2()
implementation is missing an initial svn_utf_cstring_to_utf8() call, so here's
my current plan:
path = svn_utf_cstring_to_utf8(path)
(peg_rev, path) = svn_opt_parse_path(path) # <-- new for my changes
path = svn_path_cstring_from_utf8(path)
path = apr_filepath_merge(path)
path = svn_path_cstring_to_utf8(path)
path = svn_path_canonicalize(path)
path = if peg_rev: "%s@%s" % (path, peg_rev) # <-- new for my changes
How's that look?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SEGFAULT in 'svn pget' (no time to diagnose)
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Blair Zajac wrote:
>> Is it safe to do that, given that paths are run through these steps?
>> Are there any UTF-8 issues I need to be aware of, in the following
>> Python pseudo code?
>>
>> (peg_rev, path) = svn_opt_parse_path(path)
>> path = svn_path_cstring_from_utf8(path)
>> path = apr_filepath_merge(path)
>> path = svn_path_cstring_to_utf8(path)
>> path = svn_path_canonicalize(path)
>> path = "%s@%s" % (path, peg_rev)
>
> Well, that last step would of course not re-add a peg-rev if there wasn't
> one to begin with, but other than that, I don't know of any issues with this
> path handling plan. Where in all this does conversion to internal style
> occur? Inside svn_opt_parse_path()?
>
By the way, I've filed issue #3012 to track this.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SEGFAULT in 'svn pget' (no time to diagnose)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Blair Zajac wrote:
> Is it safe to do that, given that paths are run through these steps?
> Are there any UTF-8 issues I need to be aware of, in the following
> Python pseudo code?
>
> (peg_rev, path) = svn_opt_parse_path(path)
> path = svn_path_cstring_from_utf8(path)
> path = apr_filepath_merge(path)
> path = svn_path_cstring_to_utf8(path)
> path = svn_path_canonicalize(path)
> path = "%s@%s" % (path, peg_rev)
Well, that last step would of course not re-add a peg-rev if there wasn't
one to begin with, but other than that, I don't know of any issues with this
path handling plan. Where in all this does conversion to internal style
occur? Inside svn_opt_parse_path()?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SEGFAULT in 'svn pget' (no time to diagnose)
Posted by Blair Zajac <bl...@orcaware.com>.
Blair Zajac wrote:
> C. Michael Pilato wrote:
>> Ouch.
>>
>> $ svn pget svn:mergeinfo .@BASE
>> svn: subversion/libsvn_subr/path.c:119: svn_path_join: Assertion
>> `is_canonical(base, blen)' failed.
>> Aborted (core dumped)
>>
>> I remember seeing something about svn_opt_parse_path() not canonicalizing
>> paths any more, or somesuch. Perhaps that's to blame here.
>
> I'll take a look at it.
So the problem is related to svn_opt_args_to_target_array2().
When a "." appears there, then
apr_err = apr_filepath_merge(&truenamed_target, "", apr_target,
APR_FILEPATH_TRUENAME, pool);
ends up getting a "." and converts it into a "" so its canonical.
When a ".@BASE" appears, then it's not canonicalized into "@BASE" and because
svn_opt_parse_path() no longer canonicalizes the path, "." never gets
canonicalized into "".
The documentation for svn_opt_args_to_target_array2() states:
On each local path, canonicalize case and path separators, and
silently skip it if it has the same name as a Subversion working
copy administrative directory.
Which doesn't sound exactly the same as the path is just canonicalized. Maybe
this language should be made clearer. But does
So I see two choices:
1) Make svn_opt_args_to_target_array2() smarter and have it use
svn_opt_parse_path() to split the path into path and peg revision, pass the path
into apr_filepath_merge(), then append the appropriate @PEG string back onto it.
This requires no changes from the caller, but now
svn_opt_args_to_target_array2() can return an error if somebody tries an unknown
peg revision, say @FOOBAR, when before it would not.
2) Leave svn_opt_args_to_target_array2() alone but iterate over the result of
its return in every caller of svn_opt_args_to_target_array2() to have it
canonicalize the path.
This sounds messy.
While we're in svn_opt_args_to_target_array2(), a couple of questions:
If the target is a URL, then it does this:
/* strip any trailing '/' */
target = svn_path_canonicalize(target, pool);
But this does nothing for a URL with a peg revision.
So I'm thinking of having the code use svn_opt_parse_path() before doing any
checking if the input is a URL or path, separate the path/URL from the peg
revision, then appending it at the very end.
Is it safe to do that, given that paths are run through these steps? Are there
any UTF-8 issues I need to be aware of, in the following Python pseudo code?
(peg_rev, path) = svn_opt_parse_path(path)
path = svn_path_cstring_from_utf8(path)
path = apr_filepath_merge(path)
path = svn_path_cstring_to_utf8(path)
path = svn_path_canonicalize(path)
path = "%s@%s" % (path, peg_rev)
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SEGFAULT in 'svn pget' (no time to diagnose)
Posted by Blair Zajac <bl...@orcaware.com>.
C. Michael Pilato wrote:
> Ouch.
>
> $ svn pget svn:mergeinfo .@BASE
> svn: subversion/libsvn_subr/path.c:119: svn_path_join: Assertion
> `is_canonical(base, blen)' failed.
> Aborted (core dumped)
>
> I remember seeing something about svn_opt_parse_path() not canonicalizing
> paths any more, or somesuch. Perhaps that's to blame here.
I'll take a look at it.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org