subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <>
Subject Re: AW: Segmentation Fault with SVN Client related to serf
Date Tue, 06 Jan 2015 14:01:52 GMT
<> writes:

> Here a description of the architecture we are using:
> - a http-proxy is running on which builds a secure
>   https tunnel to a special reverse proxy, using a certificate from a
>   smart-card
> - the reverse proxy then connects to the apache server used as
>   subversion server
> - the apache server uses a proprietary module for authentication using
>   a security token placed in the http header.
> - there is no authentication between the svn client and the local http-proxy
> - the svn client is not aware that it connects through a proxy
> I have tried using http instead of https for the connection between
> the svn client and the local proxy but in this case we get the
> segmentation fault by each call and not only 30% of the times...  The
> stacktrace looks very similar (I have pasted it at the end of the
> mail).
> About network traffic: I have analysed the traffic between the local
> http-proxy and the svn client because I had supposed that some packet
> length was wrongly set, but could not find any clue about the reason
> for the segmentation fault. I have compared the traffic (with a svn
> client 1.6) between using neon and using serf but could not find
> anything explaining the segmentation fault in the case we use serf.

The crash is happening in the code that parses the status line,
i.e. when handling something like

  HTTP/1.1 200 OK


  HTTP/1.1 207 Multi-Status


  HTTP/1.1 401 Authorization Required

Typically the client will first send an OPTIONS request and get back a
401 or a 200.  The client will then send further OPTIONS and PROPFIND
requests.  Can you identify which request and response is causing the
crash?  Also which, if any, requests are processed without problem
before the one that causes the crash?

It possible that something in the final request is causing the problem
but it's also possible that something in one of the earlier requests is
not handled correctly and that is the cause of the problem.  So we
really need to know the whole sequence of requests that get sent.  I
don't know how much debugging you can do with the Debian binary, it
might be easier if you install the libserf1-dbg package.  This is the
code that appears to be crashing:

Breakpoint 1, parse_status_line (ctx=0x46b758, allocator=0x4623e0)
    at buckets/response_buckets.c:148
148	    ctx->sl.reason = serf_bstrmemdup(allocator, reason,
(gdb) l
143	    if (apr_isspace(*reason)) {
144	        reason++;
145	    }
147	    /* Copy the reason value out of the line buffer. */
148	    ctx->sl.reason = serf_bstrmemdup(allocator, reason,
149	                                     ctx->linebuf.used
150	                                     - (reason - ctx->linebuf.line));
152	    return APR_SUCCESS;
(gdb) p ctx->linebuf.used
$8 = 15
(gdb) x/15c ctx->linebuf.line
0x46b788:	72 'H'	84 'T'	84 'T'	80 'P'	47 '/'	49 '1'	46 '.'	49 '1'
0x46b790:	32 ' '	50 '2'	48 '0'	48 '0'	32 ' '	79 'O'	75 'K'
(gdb) p reason
$9 = 0x46b795 "OKext/html; charset=iso-8859-1ry\"OpenSSL/1.0.1e DAV"

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

View raw message