Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of philip.martin@wandisco.com
 designates 74.125.82.177 as permitted sender)
From: Philip Martin <philip.martin@wandisco.com>
To: <pierre.viret@postfinance.ch>
Cc: <users@subversion.apache.org>
Subject: Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
References: <1434486319.700608.1420529505682.JavaMail.postmaster@post.ch>
	<878uhgb03r.fsf@ntlworld.com>
	<1332240118.440483.1420549488045.JavaMail.postmaster@post.ch>
	<87y4pg9fe7.fsf@ntlworld.com>
	<2123531229.447826.1420556241367.JavaMail.postmaster@post.ch>
	<87h9w2d7ic.fsf@ntlworld.com>
	<472712693.57162.1420703794232.JavaMail.postmaster@post.ch>
	<87ioghxuqb.fsf@ntlworld.com>
Date: Thu, 08 Jan 2015 16:26:59 +0000
In-Reply-To: <87ioghxuqb.fsf@ntlworld.com> (Philip Martin's message of "Thu,
	08 Jan 2015 13:33:32 +0000")
Message-ID: <87a91txmp8.fsf@ntlworld.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Philip Martin <philip.martin@wandisco.com> writes:

> I've converted your trace into a Python script to implement a server
> that behaves like yours.

I may have reproduced the problem.  If I remove the 'Connection: close'
headers and continue to force v1 I can get the client to crash using the
dummy server.  I suppose that means the proxy is keeping the connection
to the client open and not forwarding the 'Connection: close'.  (There
may still a performance hit if the proxy needs to keep reopening a
connection to the server.)  A socat/netcat/wireshark trace between the
client and proxy would help as it would show exactly what the proxy is
sending to the client.

valgrind shows memory use after free:

==9909== Invalid read of size 4
==9909==    at 0x6509DA5: serf_bucket_mem_alloc (allocator.c:172)
==9909==    by 0x650A048: serf_bucket_barrier_create (barrier_buckets.c:33)
==9909==    by 0x5239857: accept_response (util.c:574)
==9909==    by 0x6507DBA: read_from_connection (outgoing.c:1120)
==9909==    by 0x650800C: serf__process_connection (outgoing.c:1247)
==9909==    by 0x6505B0A: serf_event_trigger (context.c:226)
==9909==    by 0x6505C8D: serf_context_run (context.c:300)
==9909==    by 0x5239F78: svn_ra_serf__context_run (util.c:859)
==9909==    by 0x523A1D5: svn_ra_serf__context_run_wait (util.c:930)
==9909==    by 0x523A297: svn_ra_serf__context_run_one (util.c:954)
==9909==    by 0x522AC8E: svn_ra_serf__wait_for_props (property.c:653)
==9909==    by 0x522AD92: svn_ra_serf__retrieve_props (property.c:681)
==9909==  Address 0x8e8ea38 is 40 bytes inside a block of size 72 free'd
==9909==    at 0x402AF4C: free (vg_replace_malloc.c:468)
==9909==    by 0x4BB51F9: pool_clear_debug (apr_pools.c:1576)
==9909==    by 0x4BB534D: pool_destroy_debug (apr_pools.c:1638)
==9909==    by 0x4BB5436: apr_pool_destroy_debug (apr_pools.c:1680)
==9909==    by 0x6506E4B: destroy_request (outgoing.c:502)
==9909==    by 0x6507EE0: read_from_connection (outgoing.c:1186)
==9909==    by 0x650800C: serf__process_connection (outgoing.c:1247)
==9909==    by 0x6505B0A: serf_event_trigger (context.c:226)
==9909==    by 0x6505C8D: serf_context_run (context.c:300)
==9909==    by 0x5239F78: svn_ra_serf__context_run (util.c:859)
==9909==    by 0x523A1D5: svn_ra_serf__context_run_wait (util.c:930)
==9909==    by 0x523A297: svn_ra_serf__context_run_one (util.c:954)

I can't reproduce this against a standard server.  And I still don't
know how your client is switching to v1, perhaps the proxy is also
stripping the SVN-Me-Resource.  Do you know exactly which version of
Subversion is running on the server?

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*