patrick@tigris.org writes:
> Author: patrick
> Date: Sat Oct 18 09:32:20 2003
> New Revision: 7444
> Modified: trunk/subversion/bindings/java/javahl/native/SVNClient.cpp
> ==============================================================================
> --- trunk/subversion/bindings/java/javahl/native/SVNClient.cpp (original)
> +++ trunk/subversion/bindings/java/javahl/native/SVNClient.cpp Sat Oct 18 09:32:20 2003
> @@ -1638,3 +1638,99 @@
>
> return createJavaProperty(jthis, path, name, propval);
> }
> +void SVNClient::relocate(const char *from, const char *to, const char *path, bool recurse)
> +{
> + Pool subPool;
> + apr_pool_t * apr_pool = subPool.pool ();
> + m_lastPath = path;
> +
> + svn_client_ctx_t *ctx = getContext(NULL);
> + if(ctx == NULL)
> + {
> + return;
> + }
> +
> + if(from == NULL || to == NULL)
> + {
> + JNIUtil::handleSVNError(svn_error_create (SVN_ERR_CL_ARG_PARSING_ERROR, 0, ""));
> + return;
This appears to "leak" the error. Each svn_error_t is allocated in
it's own pool (unless it is chained to another svn_error_t). If you
abandon an error without calling svn_error_clear then the memory
associated with the pool (several K) will remain allocated. Do it
repeatedly in a long running application and you will run out of
memory.
> + }
> +
> + svn_error_t * error = svn_client_relocate (path != NULL? path:"", from, to, recurse, ctx, apr_pool);
> +
> + if(error != SVN_NO_ERROR)
> + {
> + JNIUtil::handleSVNError(error);
> + return;
ditto
> + }
I haven't looked at much of the java code, but the above constructs
occur in several places.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 18 16:58:46 2003