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

Re: [TSVN] Question about 2560

From: Will Dean <svn_at_indcomp.co.uk>
Date: 2005-01-28 12:00:34 CET

At 08:41 28/01/2005 +0100, you wrote:

>Deleting two files with 1.1.3 will crash. From the crashreports, I
>could see that the crash happens inside the Subversion lib. But why
>only on the second file and not the first one too? So I started
>digging: we're reusing the global pool for the deletes, and that's
>something the delete function doesn't like at all.

I've had a look at this, because I'm Mr Skeptical, and your answer didn't
ring quite true to me. I'm afraid that I don't think that you're quite
right about what's happening here.

The crash is caused because in TortoiseProc.cpp, we do an svn.ReleasePool()
after the first delete failure. This clears 'pool', which has some
important things in it like (particularly) the config, loaded with
svn_config_get_config, and referenced by m_ctx.config.

If we clear this pool, then m_ctx.config points at free'd memory and when,
down in the svn_client_delete call, SVN tries to look at its config, it

I believe that SVN::ReleasePool is fundamentally broken, in that it leaves
the SVN object irrepairably damaged, with m_ctx referencing various free'd

But it *is* necessary to release the pool which svn_client_delete has used
between each call, because otherwise the ADM cleanups don't get run, and
the second delete will fail saying that the WC is locked.

I have made the following changes:

Backed-out 2560
Removed SVN:ReleasePool altogether
Made svn_client_delete use a subpool, so that whatever happens, it
cleans-up after itself.

I don't believe that there is a requirement for something like the pathlist
array to be allocated from the *same* pool as the client function
uses. (If I'm wrong on this, there are lots of broken functions in our SVN

However, I *am* currently concerned that the error structure which is
returned by svn_client functions is allocated on the pool that the function
call is given. If this is the case, then we *do* have a lot of broken
functions which are setting the svn_error_t pointer to point to subpool
memory which is free'd very shortly afterwards.

What do y'all think...?


To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Jan 28 12:01:34 2005

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