Folks - reminder of a very old leak (which never quite made it into the
tracker for some community reason) which is still happeing.
See below for an occasional caboom which happens once in every few 100
updates; and only when a few 10k's of files are checked out or updated
(either afresh or in an existing tree).
Likely SSL related as we've not seen it yet in any file:// and http://
repos. But only in https:// repo's (with client cert auth):
.... large checkout of 500+ items....
A services/live/br......ation/SingleAnnotation.java
svn: REPORT of '/!svn/vcc/default': Could not read chunk
delimiter: Secure connection truncated
(https://repo.removed.com)
svn(22438,0xa0255500) malloc: *** mmap(size=978944)
failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Out of memory - terminating application.
Abort trap
Due to its rareness we cannot quite confirm - but it is likely related
to a transient network failure. While we cannot quite reproduce it at
will - doing a few 1000's or so svn up's of any big repo (>10Gb, taking
longer than half an hour) while intentionally doing a 'route delete/add'
every 60 seconds) is likely to trigger it once or twice in a weeks
period. The stack is too far corrupted in each and every case to get
anything sensible out of gdb.
The error message (in REPORT) is always the same; on all platforms).
With versions:
beeb:Area2point0 dirkx$ svn --version
svn, version 1.6.4 (r38063)
compiled Aug 16 2009, 16:51:33
..
* ra_neon : Module for accessing a repository via WebDAV
protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_serf : Module for accessing a repository via WebDAV
protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
This is a normal WebDAV based https repo (using the latest RHEL standard
repository (svn, version 1.4.2 (r22196) compiled Nov 20 2006, 07:17:32).
Upping client and server (and neonm, openssl, etc) to the latest version
from /trunk has not seen this problem go away.
HOWEVER it is rare enough to not be sure if upping it to the latest
version makes it more or less rare.
If you need a specific reproducible version - it has been observed
against NEON 025.0.5 and 0.28.4; and been observed with a wide range of
OpenSSL versions (such as 0.9.8k 25 Mar 2009 on FreeBSD, Linux and
MacOSX client side) and several versions on RHEL linux; including the
'official' version 'OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008'). And in each
case against SVN its /trunk, 1.6.4 and 1.4.2(red hat numbering). Seems
quite OS, byte-order and 32/64bit independent.
Thanks,
Dw.
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413231
Received on 2009-10-31 17:36:28 CET