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

svn_fs_close and svn_repos_close question

From: Yoshiki Hayashi <yoshiki_at_xemacs.org>
Date: 2002-02-06 12:13:42 CET

It turned out that native Ruby bindings was trying to
destroy same pool multiple times. This mail explains why my
previous commit to remove svn_fs_close cured the problem.
The fact is that fs was not reaching over to destroy other
pool. Rather, repos binding was reaching over to destroy fs

The original code was that Svn::Repos#close and
Svn::Fs#close called svn_repos_close and svn_fs_close
respectively. Those functions are also called from
finalization routine when those two objects are gargage

The problematic case is when Svn::Fs object is created out
of Svn::Repos by Svn::Repos#fs which calles svn_repos_fs.
svn_repos_close is implemented as calling svn_fs_close
(repos->fs). So when both objects become unreachable, both
finalizer calles svn_fs_close_fs with the same fs object.
Naturally, latter tries to destroy a pool already destroyed
and disaster happen.

So the question is, can I rely on the fact that destroying
pools svn_fs_t and svn_repos_t is allocated are equivalent
to calling svn_fs_close and svn_repos_close and then
destroying pools? The only way I can think of to solve this
problem from Ruby binding side is to add clean up function
to a pool. If it is already guaranteed that pool clean up
function will perform svn_fs_close task, I don't want to
patch over to do the same thing again.

Yoshiki Hayashi
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006

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.