Re: Recursion of copy_source_ops() causes stack overflow in Apache

On Mon, Jan 22, 2007 at 01:07:20AM -0800, Robin Boerdijk wrote:
> Hi,
>
> I am investigating an Apache crash on our production SVN server. It
> happens during a working copy update of one specific file in one
> specific SVN repository. Our production SVN server is a Windows 2000
> server running Apache 2.0.54 and SVN 1.2.3. When the Apache worker
> process crashes it leaves behind a message box showing exception code
> 0xC00000FD (stack overflow).
>
>
> I have instrumented my copy of the SVN 1.4.2 source code tree to trace
> this problem, all the way from dav_svn_deliver_report() in mod_dav_svn
> to copy_source_ops() in libsvn_delta. My conclusion is that the
> recursion of copy_source_ops() causes the stack overflow. In my case,
> the stack overflow occurred at a recursion depth of 2183.
>
> My question: Is this a bug or is it normal for copy_source_ops() to
> recurse so deep?
>

It seems likely you've found a bug in the delta combiner. I've spent
a little time looking at the code, and while it's a little.. complex in
some places, there's nothing immediate that springs out as a problem.

It would be extremely useful if you could provide access to a copy of
the repository and working copy, or if that's not feasible, to a filtered
dump of the wc and repository containing just the file that's causing a
problem (you should find that it's one particular file that causes the
problem when you commit, and a repository built from a filtered dump of
your current repository should exhibit the same problem).

If you aren't able to make the contents public (or semi-public), you could
also help by giving us more details about the recursion. For example,
which one of the three (IIRC) recursive calls to copy_source_ops()
is being used? Are the local variables at the point of recursion the
same for every iteration? Whether they are or not, could you give us
a sample of their values in a few consecutive iterations?

Sorry to ask you for so much detail, but as this is inherently a highly
data-dependent transformation, it's a lot easier if you already have a
testcase that reproduces the problem.

Regards,
Malcolm