On Jan 5, 2010, at 6:22 PM, Paul Burba wrote: > On Mon, Dec 28, 2009 at 12:49 PM, Joe Swatosh <[email protected]> wrote: >> On Sat, Dec 26, 2009 at 11:24 AM, Stefan Sperling <[email protected]> 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?
I haven't looked at the patch, but this is the proper procedure, given the drift involved. > > [[[ > 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 > <ruby.failures.1.6.x.diff>
