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.
>>>> (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;
>> 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
>> 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.
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?
Received on 2010-01-06 05:21:55 CET