Re: Any known APR_POOL_DEBUG problems?

[I've dropped dev@apr, this is Subversion specific.]

Philip Martin <philip@codematters.co.uk> writes:

> I have a Subversion test scenario that fails more often than not when
> the server (Apache, apr, mod_dav_svn) is built with APR pool debugging
> enabled. Without pool debugging it has not yet failed.

The test uses stress.pl as follows. In one xterm I run

  $ stress.pl -c -d -W -x400 -F20 -D20 -N2 -U http://localhost/repostress

which creates a repository, checks out a working copy, populates it,
commits it and then pauses waiting for me to press return. In a
second xterm I run

  $ stress.pl -d -U http://localhost/repostress

which checks out a second working copy from the same repository. Once
the checkout has started I press return in the first xterm which
triggers an update and commit of the first working copy. The update
is fast, nothing changes, the commit is slower. The commit and
checkout proceed in parallel.

The usual result is for either the checkout or the commit to fail with
an "invalid XML" error. Sometimes both fail, sometimes both complete
successfully, and very occasionally they deadlock. Failures are
always accompanied by a "reference to non-existent node" BDB error in
the Apache log, so the invalid XML error itself is probably not very
interesting. The errors usually result in a broken repository

  $ svnadmin verify repostress/
  * Verified revision 0.
  ../svn/subversion/libsvn_fs/err.c:99: (apr_err=160014)
  svn: Filesystem has no such node-rev-id
  svn: reference to non-existent node '(null).0.1' in filesystem 'repostress/db'

It's possible to trigger the problem by running the client commands
directly. Run the first stress.pl command and interrupt it using
Control-C when it pauses waiting for return. Then in the second xterm
run

  $ svn co http://localhost/repostress wc

and in the second xterm run

  $ svn ci wcstress.NNNNN

Timing is fairly critical, some of my debugging/tracing efforts were
sufficient to stop the error occurring. On my machines the commit
gets through all the "Sending" lines and moves on to printing the
"Transmitting" dots while the checkout is still producing "A" lines.

Subversion r7287, Apache APR 2.0.47 and 2.0.48-pre4, BDB 4.1.25.1.
Both single and dual processor machines, but only when the server is
built with pool debugging. These machines are not blindingly fast, if
you want to try state of the art hardware you may need to use a larger
data set, say "-x800 -F40" or "-x1600 -F80".

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org