On Tue, Jan 5, 2010 at 4:22 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> 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
>
Yay!! The Ruby bindings test failures actually caught a problem,
instead of being the problem.
--
Joe
Received on 2010-01-06 05:16:52 CET