On Tue, Jan 5, 2010 at 8:16 PM, Joe Swatosh <joe.swatosh_at_gmail.com> wrote:
> 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
>>
>
Even though this isn't happening on trunk, it occurs to be to wonder
if these tests shouldn't be included on trunk to prevent possible
segfaults in the future?
--
Joe
Received on 2010-01-06 05:21:55 CET