Re: Possible memory leak in mod_dav_svn

We'd need to know if you're talking about the svn client or server
version here; but more importantly, try it with a 1.5.0 release
candidate. 1.5 has many many improvements over 1.4.

--dave

On Wed, Jun 4, 2008 at 12:13 AM, Alexander Björnhagen
<Alexander.Bjornhagen_at_nasdaqomx.com> wrote:
> Hi Dave.
>
> Another person can reproduce this with newer versions.
>
> svn, version 1.4.6 (r28521)
> httpd, Apache/2.2.8 (Unix)
>
> http://svn.haxx.se/users/archive-2008-06/0078.shtml
>
> -----Original Message-----
> From: dglasser_at_gmail.com [mailto:dglasser_at_gmail.com] On Behalf Of David Glasser
> Sent: den 30 maj 2008 17:36
> To: Alexander Björnhagen
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Possible memory leak in mod_dav_svn
>
> 1.4.2 is relatively old by this point (we've released several patch releases in the 1.4.x line, and are on the verge of releasing 1.5.0).
> Can you reproduce this issue with one of the new 1.5.0-rc release candidates?
>
> --dave
>
> On Fri, May 30, 2008 at 3:38 AM, Alexander Björnhagen <Alexander.Bjornhagen_at_nasdaqomx.com> wrote:
>> It seems that mod_dav_svn has issues handling large operations with
>> authorization enabled.
>>
>> Our setup is a RHEL5 server with stock rpms :
>> httpd.x86_64->2.2.3-6.el5
>> mod_ssl.x86_64 -> 2.2.3-6.el5
>> mod_dav_svn.x86_64 -> 1.4.2-2.el5
>> subversion.x86_64 -> 1.4.2-2.el5
>>
>> The relevant apache config is this:
>>
>> <Location /repos>
>> LimitRequestBody 0
>> LimitXMLRequestBody 0
>> DAV svn
>> SVNParentPath /usr/local/svn/repos
>> SVNListParentPath on
>> SVNIndexXSLT /svnindex.xsl
>> AuthType Basic
>> AuthBasicProvider ldap
>> AuthzLDAPAuthoritative off
>> AuthzSVNAccessFile /etc/httpd/conf.d/subversion-authz
>> AuthLDAPURL
>> "ldap://edited:3268/DC=corp,DC=ad,DC=local?sAMAccountName?sub?(objectClass=*)"
>> NONE #Microsoft ldap
>> AuthLDAPBindDN "edited"
>> AuthLDAPBindPassword edited
>> require valid-user
>> </Location>
>>
>> The authz file could be as simple as
>> [repo:/]
>> *=rw
>>
>> The problem is that large checkouts *sometimes* fails with logs like
>> this for https:
>> [Thu May 22 15:55:30 2008] [error] [client 10.175.105.17] Provider
>> encountered an error while streaming a REPORT response. [500, #0]
>> [Thu May 22 15:55:30 2008] [error] [client 10.175.105.17] A failure
>> occurred while driving the update report editor [500, #104] [Thu May
>> 22 15:55:30 2008] [error] [client 10.175.105.17] Error writing
>> base64 data: Connection reset by peer [500, #104]
>>
>> And entries like this for http:
>> [Thu May 22 15:59:35 2008] [error] [client 10.112.152.135] Provider
>> encountered an error while streaming a REPORT response. [500, #0]
>> [Thu May 22 15:59:35 2008] [error] [client 10.112.152.135] A failure
>> occurred while driving the update report editor [500, #190004]
>>
>> On the client the error is typically:
>>
>> svn: REPORT request failed on '/svn/repo/!svn/vcc/default'
>> svn: REPORT of '/svn/repo/!svn/vcc/default': Could not read chunk delimiter:
>> Secure connection truncated (https://svn.myco.com)
>>
>> We have tried to nail down why it only fails sometimes, but this is
>> consistent accross networks and different clients etc. Local checkouts
>> via file:/// always works.
>>
>> After much googling the only thing that helps is setting:
>>
>> SVNPathAuthz off
>>
>> which is not good enough security wise for our purposes. I found out
>> about this by reading this:
>>
>> http://www.sharp-tools.net/archives/000928.html
>>
>> which is the only reference to this exact issue that I can find. I
>> tried to leave a post on that page to ask exactly how they found out
>> that there was a memory leak but the comment system is broker (server
>> 500 page :(
>>
>> Another possible workaround would be to set up a cron job like this
>> (at least it *seems* to work for us although I have not tested it long
>> enough and definetly not put it into production... )
>>
>> * * * * * /etc/init.d/httpd configtest 2>/dev/null &&
>> /etc/init.d/httpd graceful #guarantee that every http requset gets a
>> newly started fresh thread
>>
>> Seems I'm not the only one asking:
>>
>> http://groups.google.se/group/linux.debian.bugs.dist/browse_thread/thr
>> ead/d14c54c3b8a56255 http://svn.haxx.se/dev/archive-2008-02/0628.shtml
>>
>> Anyway it makes sense that http worker threads leak memory and then at
>> some point just die and drop their connections.
>>
>> How can I verify the memory leaking and supply more concrete info ? (
>> I'd rather not sit and stare at top and hope to catch defunct
>> processes since the errors occurs say five times per day )
>>
>> Regards,
>>
>> Alex B
>>
>>
>> Legal Disclaimer:
>> ***********************************************************
>> This e-mail and the information it contains may be privileged and/or
>> confidential.
>> It is for the intended addressee(s) only.
>> The unauthorized use, disclosure or copying of this e-mail, or any
>> information it contains, is prohibited.
>> If you are not an intended recipient, please contact the sender and
>> delete the material from your computer.
>> ***********************************************************
>>
>
>
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
> Legal Disclaimer:
> ***********************************************************
> This e-mail and the information it contains may be privileged and/or confidential.
> It is for the intended addressee(s) only.
> The unauthorized use, disclosure or copying of this e-mail, or any information it contains, is prohibited.
> If you are not an intended recipient, please contact the sender and delete the material from your computer.
> ***********************************************************
>
>

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org