svn import/svn_client_import Segfault

On me travels today, stumbled across a heinous little bug in
svn_client_import in libsvn_client/commit.c

Durring svn_client_import, 'subpool' is created as a child of 'pool'. If an
fs-module is dynamically loaded (from 'get_ra_editor'), it is done with
'subpool'. The actual transaction ('import') ; however, will be done in
'pool'.

In the case of BerkelyDB, control will eventually flow to
'svn_fs_base__track_dbt', where 'apr_pool_cleanup_register' will be called
to register a free function ('apr_free_cleanup') for the trail.

Problem is that the trail has created a subpool as well...but in the parent.
When apr_destroy_pool is called on the parent, 'subpool' wil get destroyed
first triggering apr_dso_unload on the fs-module...and eventually apr will
try to call 'apr_free_cleanup', but it's been unloaded.

Attached is a patch that fixes this, calling import with the subpool, and
destroying it as well.

--- subversion/libsvn_client/commit.c Wed Mar 30 23:02:40 2005
+++ subversion/libsvn_client/commit.c Tue Apr 12 14:33:37 2005
@@ -708,12 +708,14 @@
   /* If an error occurred during the commit, abort the edit and return
      the error. We don't even care if the abort itself fails. */
   if ((err = import (path, new_entries, editor, edit_baton,
- nonrecursive, excludes, ctx, pool)))
+ nonrecursive, excludes, ctx, subpool)))
     {
       svn_error_clear (editor->abort_edit (edit_baton, pool));
       return err;
     }
-
+
+ svn_pool_destroy(subpool);
+
   return SVN_NO_ERROR;
 }
 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org