On Tue, 2002-11-12 at 12:21, Branko Èibej wrote:
> Except when we call svn_error_compose to splice two errors together.
> When that happens (I count six places right now), we get a chain of
> errors that aren't all allocated from the same pool, which means that
> svn_error_clear is bound to leak memory.
I hadn't thought of this. I can see two solutions:
* Ditch svn_error_compose(). It's used in three places (three times
in libsvn_client/commit.c, twice in libsvn_client/copy.c, once in
clients/cmdline/util.c). We could argue that error chains should never
be composed because errors should always flow from most specific to
least specific.
In commit.c and copy.c, this means not reporting errors which might
occur in svn_wc_adm_close() and remove_tmpfiles() when there is an error
bumping revisions or committing. (I'm not sure why we're not just
relying on pool cleanup handlers, really; then we could just use SVN_ERR
instead of going through all these hoops.)
In clients/cmdline/util.c, in the unlikely case where we can't convert
the temporary filename from UTF-8 to the native charset, we could just
report the UTF-8 string for the temp file, or something.
* Allocate each error in a separate pool. (I'm not worried about the
inefficiency here; errors are uncommon and error chains are short.)
Change the svn_error_clear() contract to only clear an error and its
descendents, since the pools of ancestors are no longer reachable.
Provide an svn_error_clear_one() to clear a single error (so that you
can pass its child back to the caller); or just expect code to do:
newerr = err->child;
err->child = NULL;
svn_error_clear(err);
in that uncommon case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 13 20:47:13 2002