On Mon, Dec 28, 2009 at 12:49 PM, Joe Swatosh <joe.swatosh_at_gmail.com> wrote:
> On Sat, Dec 26, 2009 at 11:24 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Wed, Dec 23, 2009 at 09:35:23AM -0600, Hyrum K. Wright wrote:
>>> Please be sure to test the bindings.
>>
>> Also, a ruby bindings test segfaults.
>>
>> I've found this in an OpenBSD ports build, hence no debug symbols
>> in this trace. I can rebuild it with debug symbols if required.
>>
>> Trace:
>>
>> (gdb) bt
>> #0 0x007f64b5 in kill () from /usr/lib/libc.so.53.0
>> #1 0x0084365b in abort () at /usr/src/lib/libc/stdlib/abort.c:68
>> #2 0x049a0e22 in rb_bug () from /usr/local/lib/libruby.so.2.0
>> #3 0x049ff537 in sigsegv () from /usr/local/lib/libruby.so.2.0
>> #4 <signal handler called>
>> #5 0x074077ec in svn_path_join () from /usr/local/lib/libsvn_subr-1.so.1.2
>
> On trunk resolve_conflict_on_entry is only called once for these
> resolve tests. On branch it is called three times, the first two with
> an apparently blank/empty svn_wc_entry_t. The following causes the
> tests to not segfault, but is only provided with the hope of helping
> some expert figure out the proper fix.
>
> Index: subversion/libsvn_wc/adm_ops.c
> ===================================================================
> --- subversion/libsvn_wc/adm_ops.c (revision 894204)
> +++ subversion/libsvn_wc/adm_ops.c (working copy)
> @@ -2739,6 +2739,10 @@
> apr_uint64_t modify_flags = 0;
> svn_wc_entry_t *entry = svn_wc_entry_dup(orig_entry, pool);
>
> + /* if we there is nothing to try to resolve, just skip it all */
> + if (strcmp(entry->name, "") == 0)
> + return SVN_NO_ERROR;
> +
> if (resolve_text)
> {
> const char *auto_resolve_src;
>
>
>
> --
> Joe
Hi All,
This prompted me to finally build Ruby and get the bindings working on
Windows, which took far longer than fixing the actual problem :-D
Anyway, the segfault is due to the changes Stefan made to
subversion/libsvn_wc/adm_ops.c:resolve_conflict_on_entry() in r880533
on the 1.6.x-r40452 branch
(http://svn.apache.org/viewvc?view=revision&revision=880533). That
change fixed the bug Stefan mentioned in r880532 (i.e. "svn: warning:
Can't open file '....svn/tmp/tempfile.tmp': No such file or
directory") but introduced this segfault. You can replicate it from
the command line by attempting to resolve a text-conflict with 'svn
resolve [base | mine-full | theirs-full] -R' on some parent directory
of the conflicted text file.
The attached patch against 1.6.x fixes the error. The [ra_local x
fsfs], Ruby binding, and JavaHL tests all pass with it.
Given the code drift that has occurred between trunk and 1.6.x, this
fix cannot be made on the former and backported.
libsvn_wc/adm_ops.c:resolve_conflict_on_entry() is now
libsvn_wc\conflicts.c:resolve_conflict_on_node() and with its wc-ng
implementation bears little resemblance to what is on 1.6.x (note that
this error does *not* exist on trunk).
Assuming my fix looks right, how do we do this? Create a "backport"
branch from 1.6.x, make the change there, and nominate it for backport
yes?
[[[
Fix segfault with 'svn resolve [mine-full | base | theirs-full]'.
Follow-up to r880533 on the ^/subversion/branches/1.6.x-r40452 branch.
* subversion/libsvn_wc/adm_ops.c
(resolve_conflict_on_entry): Don't try to join NULL paths.
]]]
Paul
Received on 2010-01-06 01:22:40 CET