need eyeballs on ra_dav

``Given enough eyeballs, all bugs are shallow.'' --Eric Raymond

This is a call for eyeballs on libsvn_ra_dav.

Mike Pilato and I have spent all day chasing a huge memory leak in
ra_dav. How do we know it's in libsvn_ra_dav? By process of
elimination:

* if you import the mozilla source tree via ra_dav,

        httpd stays at an even 7M
        svn client grows unbounded, up to 162M+ <-- Bad, Bad, Bad

* if you import the mozilla source tree over ra_svn,

        svnserve stays at an even 1M
        svn client stays at an even 5M

* if you import the mozilla source tree over ra_local,

        svn client stays at an even 7M

We also tried the ra_dav import using svn-0.28.2, which was the last
release to use the 'old' neon 0.23 API. No difference. This means
that the leak isn't happening because of the new neon-0.24, or the
'shim' code for it.

Thus, by process of elimination, libsvn_ra_dav is our culprit.

In the last 24 hours, cmpilato has gone over libsvn_ra_dav/commit.c
and merge.c with a fine-tooth comb, and fixed many pool abuses. (We
were doing too much work in ras->pool, rather than in the pools handed
to us by the editor.) Mike also fixed many abuses of non-cleared
errors, which fixed some leaks in libsvn_client and libsvn_wc. But
the numbers reported above are all *after* the latest fixes (r7378).
We still have a huge bug in ra_dav somewhere.

Can some other developers scan ra_dav for pool abuses?

We're also hoping that Joe Orton can audit our use of neon -- maybe
we're doing something silly, forgetting to free a request somewhere.
Or maybe there's some giant hidden memory bug in both neon 0.23 *and*
0.24... ?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 11 00:02:45 2003