On Mon, Dec 28, 2009 at 12:49 PM, Joe Swatosh <joe.swatosh@gmail.com> wrote=
:
> On Sat, Dec 26, 2009 at 11:24 AM, Stefan Sperling <stsp@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 =C2=A00x007f64b5 in kill () from /usr/lib/libc.so.53.0
>> #1 =C2=A00x0084365b in abort () at /usr/src/lib/libc/stdlib/abort.c:68
>> #2 =C2=A00x049a0e22 in rb_bug () from /usr/local/lib/libruby.so.2.0
>> #3 =C2=A00x049ff537 in sigsegv () from /usr/local/lib/libruby.so.2.0
>> #4 =C2=A0<signal handler called>
>> #5 =C2=A00x074077ec 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. =C2=A0On branch it is called three times, the first two wi=
th
> an apparently blank/empty svn_wc_entry_t. =C2=A0The following causes the
> tests to not segfault, but is only provided with the hope of =C2=A0helpin=
g
> some expert figure out the proper fix.
>
> Index: subversion/libsvn_wc/adm_ops.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- subversion/libsvn_wc/adm_ops.c =C2=A0 =C2=A0 =C2=A0(revision 894204)
> +++ subversion/libsvn_wc/adm_ops.c =C2=A0 =C2=A0 =C2=A0(working copy)
> @@ -2739,6 +2739,10 @@
> =C2=A0 apr_uint64_t modify_flags =3D 0;
> =C2=A0 svn_wc_entry_t *entry =3D svn_wc_entry_dup(orig_entry, pool);
>
> + =C2=A0/* if we there is nothing to try to resolve, just skip it all */
> + =C2=A0if (strcmp(entry->name, "") =3D=3D 0)
> + =C2=A0 =C2=A0return SVN_NO_ERROR;
> +
> =C2=A0 if (resolve_text)
> =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 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=3Drevision&revision=3D880533). 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
|