Hi

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.

Are there any known problems with APR pool debugging? I realise that
pool debugging will change memory usage, CPU usage, timing, cache
footprint, etc., all of which are enough to explain the difference,
but I thought I would check if there are known problems before
spending too much time investigating the Subversion bug.

The error is a Subversion Berkeley DB error when running a checkout
and commit simultaneously, either:

[Sat Oct 04 14:31:05 2003] [error] [client 127.0.0.1] Provider encountered an 
error while streaming a REPORT response.  [500, #0]
[Sat Oct 04 14:31:05 2003] [error] [client 127.0.0.1] A failure occurred while 
driving the update report editor  [500, #160014]
[Sat Oct 04 14:31:05 2003] [error] [client 127.0.0.1] reference to non-existent 
node '(null).0.1' in filesystem '/home/pm/sw/subversion/obj/repostress/db'  
[500, #160014]

or:

[Sat Oct 04 14:31:37 2003] [error] [client 127.0.0.1] Could not MERGE resource 
"/obj/repostress/!svn/act/1add337e-dcc8-0310-9bef-f477c27520b2" into 
"/obj/repostress/trunk".  [500, #0]
[Sat Oct 04 14:31:37 2003] [error] [client 127.0.0.1] could not process the 
merge delta.  [500, #160014]
[Sat Oct 04 14:31:37 2003] [error] [client 127.0.0.1] (2)No such file or 
directory: reference to non-existent node '(null).0.4' in filesystem 
'/home/pm/sw/subversion/obj/repostress/db'  [500, #160014]

I am using the prefork MPM on Linux, and Subversion HEAD (r7287).  The
error occurs on both single processor and dual processor machines, and
with both Apache 2.0.47 and STRIKER_2_0_48_PRE4.

-- 
Philip Martin

Reply via email to