We've never been very focused on those kinds of "leaks", on the
assumption that the parent or child pool will be cleared at some
point, thus free'ing the handle.
Cheers,
-g
On Sat, Sep 18, 2010 at 13:47, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> http://colabti.org/irclogger/irclogger_log/svn-dev?date=2010-09-07#l40
> describes a scenario where a file handle would be leaked due to a pool
> not being freed; specifically,
>
> parent(pool) calls child(pool);
> child(pool) allocates handle from POOL;
> child(pool) triggers an SVN_ERR();
> handle remains allocated.
>
> Are there any other cases where this would be a problem?
>
>
> Should we adopt a strategy of
>
> #define SVN_ERR_CLEAR(expr, scratch_pool)
> do {
> svn_error_clear(scratch_pool);
> SVN_ERR(expr);
> } while(0)
>
> at least in some functions taking a scratch_pool argument?
>
>
> (We could have this only for maintainer-mode builds, and
> #define SVN_ERR_CLEAR(expr, pool) SVN_ERR(expr)
> for normal builds.)
>
>
Received on 2010-09-18 21:58:24 CEST