[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Fix memory leak like situation when parsing a svn_config_t object repeatedly

From: Bernd Rinn <bernd_at_sdf.lonestar.org>
Date: 2005-07-24 10:41:02 CEST

Of course you are right with the not "thread safe" part, the problem is
just too obvious, sorry. :-(

Greg Hudson wrote:
> On Sun, 2005-07-24 at 02:11 +0100, Philip Martin wrote:
>
>>Neither svn_config_enumerate nor svn_config_enumerate_sections get
>>passed a pool, they use the one in svn_config_t.
>
>
> Ah, I apologize; I misunderstood the situation.
>
>
>>We could make the enumerate functions use a subpool, they do iterate
>>after all, or we could rev the API to include a pool.
>
>
> The standard workaround for having to use a baton pool instead of a
> passed-in pool is to use a subpool of the baton pool, yes. Since we're
> iterating here, it isn't even terribly awkward. But yes, the API should
> include a pool, although it's not terribly important.

Maybe I explain the use case so that you can see it is a useful one:

I want to call

  svn_repos_authz_read(&authz, file, TRUE, conf_pool)

once and

  svn_repos_authz_check_access(authz, repos_name, path, user,
required_access, &OK, request_pool)

many times in a long running server process, calling
svn_pool_clear(request_pool) after each authorization request, as is
suggested by section "APR pool usage conventions" of HACKING. This way
it can be avoided to have the overhead of parsing and expanding the same
authz file for each authorization request.

svn_repos_authz_check_access() calls svn_config_enumerate() and
svn_config_enumerate_sections() to do the work of scanning through the
configuration, and here is the problem: despite being provided a pool,
svn_repos_authz_check_access() doesn't use this pool for all its memory
allocations. Instead, it uses authz->cfg>x_pool for a part of it.

--
Bernd Rinn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 24 10:42:22 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.