Re: AW: Segmentation Fault with SVN Client related to serf

<pierre.viret_at_postfinance.ch> writes:

> Here a description of the architecture we are using:
> - a http-proxy is running on 127.0.0.1:7771 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

or

  HTTP/1.1 207 Multi-Status

or

  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 }
146
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));
151
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*