You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2008/08/11 18:54:03 UTC
Re: svn 1.5.0 segfaults with ^/ externals
On Wed, 2008-07-16 at 11:48 -0700, Blair Zajac wrote:
> Thanks for the report. I'll take a look at this one.
> Stefan Küng wrote:
> > Another crash report sent for TSVN: when setting an svn:external to
> > ^/B extfolder
> > svn can segfault.
> > The script below shows how to reproduce this. It only works if the
> > repository is located directly on the server root (e.g.,
> > svn://localhost/), it works ok if the repository is at least one folder
> > below the server root.
I converted the reproduction script to a Bourne shell script, attached,
and it shows the problem on my GNU/Linux system.
Program received signal SIGSEGV, Segmentation fault.
0xb7da23df in svn_path_canonicalize (path=0x0, pool=0x809c230)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:1253
1253 if (! *path)
(gdb) bt
#0 0xb7da23df in svn_path_canonicalize (path=0x0, pool=0x809c230)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:1253
#1 0xb7da25f8 in svn_path_is_canonical (path=0x0, pool=0x809c230)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:1345
#2 0xb7da1678 in svn_path_decompose (path=0x0, pool=0x809c230)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:736
#3 0xb7f7190d in resolve_relative_external_url (item=0x809ce88,
repos_root_url=0x809c6b0 "svn://localhost:40000",
parent_dir_url=0x809d0d0 "svn://localhost:40000/A", pool=0x809c230)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:401
#4 0xb7f71c7a in handle_external_item_change (key=0x809ceb8, klen=-1,
status=svn_hash_diff_key_both, baton=0xbfb2d7c4)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:500
#5 0xb7f7248d in handle_externals_desc_change (key=0x809c928, klen=8,
status=svn_hash_diff_key_both, baton=0xbfb2d8a4)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:786
#6 0xb7d9239f in svn_hash_diff (hash_a=0x809c278, hash_b=0x809c2e0,
diff_func=0xb7f720cc <handle_externals_desc_change>,
diff_func_baton=0xbfb2d8a4, pool=0x809c230)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/hash.c:412
#7 0xb7f726b7 in svn_client__handle_externals (
traversal_info=0x809c268,
from_url=0x809cb08 "svn://localhost:40000/A",
to_path=0x809c410 "relextwc",
repos_root_url=0x809c6b0 "svn://localhost:40000",
requested_depth=svn_depth_unknown, update_unchanged=1,
timestamp_sleep=0xbfb2da7c, ctx=0x8080678, pool=0x809c230)
at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:846
[...]
So the problem is in (#3) resolve_relative_external_url() which passes
the "path" field from apr_uri_parse(), which may be null, to
svn_path_decompose() which requires a non-null path string. There are
two branches of the code (if ... else ...) that both potentially do
this.
Sounds like a bite-sized fix. Anyone fancy taking this one?
- Julian
Re: svn 1.5.0 segfaults with ^/ externals
Posted by Blair Zajac <bl...@orcaware.com>.
Julian Foad wrote:
> On Wed, 2008-07-16 at 11:48 -0700, Blair Zajac wrote:
>> Thanks for the report. I'll take a look at this one.
>
>> Stefan Küng wrote:
>>> Another crash report sent for TSVN: when setting an svn:external to
>>> ^/B extfolder
>>> svn can segfault.
>>> The script below shows how to reproduce this. It only works if the
>>> repository is located directly on the server root (e.g.,
>>> svn://localhost/), it works ok if the repository is at least one folder
>>> below the server root.
>
> I converted the reproduction script to a Bourne shell script, attached,
> and it shows the problem on my GNU/Linux system.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7da23df in svn_path_canonicalize (path=0x0, pool=0x809c230)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:1253
> 1253 if (! *path)
>
> (gdb) bt
> #0 0xb7da23df in svn_path_canonicalize (path=0x0, pool=0x809c230)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:1253
> #1 0xb7da25f8 in svn_path_is_canonical (path=0x0, pool=0x809c230)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:1345
> #2 0xb7da1678 in svn_path_decompose (path=0x0, pool=0x809c230)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/path.c:736
> #3 0xb7f7190d in resolve_relative_external_url (item=0x809ce88,
> repos_root_url=0x809c6b0 "svn://localhost:40000",
> parent_dir_url=0x809d0d0 "svn://localhost:40000/A", pool=0x809c230)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:401
> #4 0xb7f71c7a in handle_external_item_change (key=0x809ceb8, klen=-1,
> status=svn_hash_diff_key_both, baton=0xbfb2d7c4)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:500
> #5 0xb7f7248d in handle_externals_desc_change (key=0x809c928, klen=8,
> status=svn_hash_diff_key_both, baton=0xbfb2d8a4)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:786
> #6 0xb7d9239f in svn_hash_diff (hash_a=0x809c278, hash_b=0x809c2e0,
> diff_func=0xb7f720cc <handle_externals_desc_change>,
> diff_func_baton=0xbfb2d8a4, pool=0x809c230)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_subr/hash.c:412
> #7 0xb7f726b7 in svn_client__handle_externals (
> traversal_info=0x809c268,
> from_url=0x809cb08 "svn://localhost:40000/A",
> to_path=0x809c410 "relextwc",
> repos_root_url=0x809c6b0 "svn://localhost:40000",
> requested_depth=svn_depth_unknown, update_unchanged=1,
> timestamp_sleep=0xbfb2da7c, ctx=0x8080678, pool=0x809c230)
> at /home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/externals.c:846
> [...]
>
> So the problem is in (#3) resolve_relative_external_url() which passes
> the "path" field from apr_uri_parse(), which may be null, to
> svn_path_decompose() which requires a non-null path string. There are
> two branches of the code (if ... else ...) that both potentially do
> this.
>
> Sounds like a bite-sized fix. Anyone fancy taking this one?
I'll take a look at that one, it's probably my code.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org