You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Barry Scott <ba...@barrys-emacs.org> on 2013/06/02 17:10:57 UTC
Segv in 1.8.0-rc2 used svn_client_status4 with a tree conflict
I found this while running the pysvn regression tests against svn 1.8.0-rc2.
I get the following segv back trace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff918076b0 in strlen ()
(gdb) bt
#0 0x00007fff918076b0 in strlen ()
#1 0x000000010144e1a2 in apr_pstrdup ()
#2 0x000000010065d5f9 in svn_wc__cd2_to_cd (conflict=0x100713f76, result_pool=0x1008e4428) at subversion/libsvn_wc/util.c:354
#3 0x000000010065da47 in svn_wc__status2_from_3 (status=0x7fff5fbfe0f8, old_status=0x1008fb138, wc_ctx=0x100890158, local_abspath=0x1008f5d10 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test/file4.txt", result_pool=0x1008e4428, scratch_pool=0x1008e4428) at subversion/libsvn_wc/util.c:453
#4 0x000000010050edb9 in status4_wrapper_func (baton=0x7fff5fbfec98, path=0x1008fb288 "file4.txt", status=0x1008fb298, scratch_pool=0x1008e4428) at subversion/libsvn_client/deprecated.c:2208
#5 0x000000010055e286 in tweak_status (baton=0x7fff5fbfeb70, local_abspath=0x1008e44a0 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test/file4.txt", status=0x1008fb138, scratch_pool=0x1008e4428) at subversion/libsvn_client/status.c:109
#6 0x000000010064417d in send_status_structure (wb=0x7fff5fbfe7d0, local_abspath=0x1008e44a0 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test/file4.txt", parent_repos_root_url=0x1008b5160 "file:///Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/repos", parent_repos_relpath=0x1008b5150 "trunk/test", parent_repos_uuid=0x1008b51a8 "acfe58c3-85ae-4c76-95e8-1a27ba74d63a", info=0x1008b57f0, dirent=0x1008b4f80, get_all=1, status_func=0x10055e120 <tweak_status>, status_baton=0x7fff5fbfeb70, scratch_pool=0x1008e4428) at subversion/libsvn_wc/status.c:930
#7 0x0000000100643c52 in one_child_status (wb=0x7fff5fbfe7d0, local_abspath=0x1008e44a0 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test/file4.txt", parent_abspath=0x1008b4250 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test", info=0x1008b57f0, dirent=0x1008b4f80, dir_repos_root_url=0x1008b5160 "file:///Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/repos", dir_repos_relpath=0x1008b5150 "trunk/test", dir_repos_uuid=0x1008b51a8 "acfe58c3-85ae-4c76-95e8-1a27ba74d63a", unversioned_tree_conflicted=1, collected_ignore_patterns=0x7fff5fbfe5f8, ignore_patterns=0x1008b4298, depth=svn_depth_infinity, get_all=1, no_ignore=1, status_func=0x10055e120 <tweak_status>, status_baton=0x7fff5fbfeb70, cancel_func=0, cancel_baton=0x0, result_pool=0x1008b4028, scratch_pool=0x1008e4428) at subversion/libsvn_wc/status.c:1206
#8 0x0000000100641c83 in get_dir_status (wb=0x7fff5fbfe7d0, local_abspath=0x1008b4250 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test", skip_this_dir=0, parent_repos_root_url=0x0, parent_repos_relpath=0x0, parent_repos_uuid=0x0, dir_info=0x1008b4378, dirent=0x1008b4d60, ignore_patterns=0x1008b4298, depth=svn_depth_infinity, get_all=1, no_ignore=1, status_func=0x10055e120 <tweak_status>, status_baton=0x7fff5fbfeb70, cancel_func=0, cancel_baton=0x0, scratch_pool=0x1008b4028) at subversion/libsvn_wc/status.c:1441
#9 0x0000000100640997 in svn_wc__internal_walk_status (db=0x100890170, local_abspath=0x1008b4250 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test", depth=svn_depth_infinity, get_all=1, no_ignore=1, ignore_text_mods=0, ignore_patterns=0x1008b4298, status_func=0x10055e120 <tweak_status>, status_baton=0x7fff5fbfeb70, cancel_func=0, cancel_baton=0x0, scratch_pool=0x1008b4028) at subversion/libsvn_wc/status.c:2746
#10 0x0000000100642109 in svn_wc_walk_status (wc_ctx=0x100890158, local_abspath=0x1008b4250 "/Users/barry/wc/svn/pysvn-next/Extension/Tests/testroot-01/wc2/test", depth=svn_depth_infinity, get_all=1, no_ignore=1, ignore_text_mods=0, ignore_patterns=0x1008b4298, status_func=0x10055e120 <tweak_status>, status_baton=0x7fff5fbfeb70, cancel_func=0, cancel_baton=0x0, scratch_pool=0x1008b4028) at subversion/libsvn_wc/status.c:2805
#11 0x000000010055df47 in svn_client_status5 (result_rev=0x7fff5fbfee98, ctx=0x1008900a0, path=0x7fff7d073588 "", revision=0x7fff5fbfee88, depth=svn_depth_infinity, get_all=1, update=0, no_ignore=1, ignore_externals=0, depth_as_sticky=1, changelists=0x0, status_func=0x10050ed30 <status4_wrapper_func>, status_baton=0x7fff5fbfec98, pool=0x1008b4028) at subversion/libsvn_client/status.c:574
#12 0x000000010050ed1a in svn_client_status4 (result_rev=0x7fff5fbfee98, path=0x7fff7d073588 "", revision=0x7fff5fbfee88, status_func=0x1010faf60 <StatusEntriesFunc>, status_baton=0x7fff5fbfee78, depth=svn_depth_infinity, get_all=1, update=0, no_ignore=1, ignore_externals=0, changelists=0x0, ctx=0x1008900a0, pool=0x1008b4028) at subversion/libsvn_client/deprecated.c:2236
#13 0x00000001010fa37b in pysvn_client::cmd_status (this=0x10037a110, a_args=@0x7fff5fbff168, a_kws=@0x7fff5fbff158) at pysvn_client_cmd_info.cpp:1321
#14 0x0000000101091846 in Py::PythonExtension<pysvn_client>::method_keyword_call_handler (_self_and_name_tuple=0x100490830, _args=0x100485e10, _keywords=0x0)
The problem can be traced to a bug in svn_wc__get_tree_conflict failed to init tree_conflict on
all error paths.
Index: /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
===================================================================
--- /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c (revision 1484244)
+++ /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c (working copy)
@@ -506,6 +506,7 @@
return SVN_NO_ERROR;
}
}
+ *tree_conflict = NULL;
return SVN_NO_ERROR;
}
Barry
Re: Separating deprecated code.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/03/2013 04:32 AM, Philip Martin wrote:
> This is a patch to svn_wc__get_tree_conflict which is only called from
> util.c:svn_wc__status2_from_3 which is itself only called in the main
> code from libsvn_wc/deprecated.c and libsvn_client/deprecated.c. That
> makes both svn_wc__get_tree_conflict and svn_wc__status2_from_3 only
> necessary for support of the deprecated API.
>
> Should we move the code to deprecated.c? Should we add DEPRECATED
> markings? conflict-data-test.c also calls svn_wc__get_tree_conflict
> which makes it an explicit test of the deprecated code. If we mark the
> functions DEPRECATED do we explicitly disable DEPRECATED warnings in the
> test file?
No strong opinion about the above, but at a minimum we should comment the
two functions to explain their existence. I mean, even if we do all that
you've asked about, we'd still want to have a comment in place explaining
why we bothered to keep around private, deprecated functions.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Separating deprecated code.
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Barry Scott <ba...@barrys-emacs.org> writes:
>
>> Index: /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
>> ===================================================================
>> --- /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c (revision 1484244)
>> +++ /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c (working copy)
>> @@ -506,6 +506,7 @@
>> return SVN_NO_ERROR;
>> }
>> }
>> + *tree_conflict = NULL;
>> return SVN_NO_ERROR;
>> }
>
> Committed to trunk and nominated for backport. Thanks!
This is a patch to svn_wc__get_tree_conflict which is only called from
util.c:svn_wc__status2_from_3 which is itself only called in the main
code from libsvn_wc/deprecated.c and libsvn_client/deprecated.c. That
makes both svn_wc__get_tree_conflict and svn_wc__status2_from_3 only
necessary for support of the deprecated API.
Should we move the code to deprecated.c? Should we add DEPRECATED
markings? conflict-data-test.c also calls svn_wc__get_tree_conflict
which makes it an explicit test of the deprecated code. If we mark the
functions DEPRECATED do we explicitly disable DEPRECATED warnings in the
test file?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Segv in 1.8.0-rc2 used svn_client_status4 with a tree conflict
Posted by Philip Martin <ph...@wandisco.com>.
Barry Scott <ba...@barrys-emacs.org> writes:
> Index: /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
> ===================================================================
> --- /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c (revision 1484244)
> +++ /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c (working copy)
> @@ -506,6 +506,7 @@
> return SVN_NO_ERROR;
> }
> }
> + *tree_conflict = NULL;
> return SVN_NO_ERROR;
> }
Committed to trunk and nominated for backport. Thanks!
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download