On Tue, Jan 5, 2010 at 8:16 PM, Joe Swatosh <[email protected]> wrote: > On Tue, Jan 5, 2010 at 4:22 PM, Paul Burba <[email protected]> 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? >> >> [[[ >> 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
