[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: Segmentation Fault with SVN Client related to serf

From: <pierre.viret_at_postfinance.ch>
Date: Tue, 6 Jan 2015 13:04:45 +0000

> -----Ursprüngliche Nachricht-----
> Von: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Gesendet: Dienstag, 6. Januar 2015 12:49
> An: Viret Pierre, PF54
> Cc: users_at_subversion.apache.org
> Betreff: Re: Segmentation Fault with SVN Client related to serf
>
> <pierre.viret_at_postfinance.ch> writes:
>
> > viretp@mwbox:~$ svn ls https://127.0.0.1:7771/svn/t_sponis_testrepo
> > Segmentation fault
> >
> > In /var/log/syslog:
> > Jan 5 14:31:23 mwbox kernel: [14750.072747] svn[21822]: segfault at
> > 7f3733f39000 ip 00007f37328ae3cf sp 00007fff9e3df468 error 7 in
> > libc-2.13.so[7f373278a000+182000]
> >
> >
> > Here the stacktrace with gdb:
> >
> > (gdb) bt
> > #0 __memcpy_ssse3 () at
> > ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2833
> > #1 0x00007ffff35f6fa3 in serf_bstrmemdup () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #2 0x00007ffff35faecb in ?? () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #3 0x00007ffff35fb2d4 in serf_bucket_response_status () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #4 0x00007ffff35fe219 in serf__handle_auth_response () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #5 0x00007ffff35f4f29 in serf__process_connection () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #6 0x00007ffff35f38ae in serf_event_trigger () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #7 0x00007ffff35f39d9 in serf_context_run () from
> > /usr/lib/x86_64-linux-gnu/libserf-1.so.1
> > #8 0x00007ffff573b522 in svn_ra_serf__context_run_wait () from
> > /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
>
> What sort of authentication are you using on your proxy and webserver?
> Is there authentication for the proxy? Is the client handling proxy or apache
> authentication when it crashed? Are you using one of the password stores? It
> might be helpful to look at the network traffic although this can be tricky with https.
> One way that may work is to use a socat proxy:
>
> socat -v TCP-LISTEN:9630,reuseaddr,fork OPENSSL:127.0.0.1:7771,verify=0
>
> and then use http://localhost:9630/ instead of https://localhost:7771/ in your
> Subversion command. You may need to use TCP6-LISTEN.
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*

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.

viretp_at_mwbox:~/work/APLAT-105/tests/debian$ gdb svn
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/svn...(no debugging symbols found)...done.
(gdb) run ls http://127.0.0.1:7771/svn/t_sponis_testrepo
Starting program: /usr/bin/svn ls http://127.0.0.1:7771/svn/t_sponis_testrepo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2833
2833 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory.
(gdb) bt
#0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2833
#1 0x00007ffff35f6fa3 in serf_bstrmemdup () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#2 0x00007ffff35faecb in ?? () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#3 0x00007ffff35fb2d4 in serf_bucket_response_status () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#4 0x00007ffff35fe219 in serf__handle_auth_response () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#5 0x00007ffff35f4f29 in serf__process_connection () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#6 0x00007ffff35f38ae in serf_event_trigger () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#7 0x00007ffff35f39d9 in serf_context_run () from /usr/lib/x86_64-linux-gnu/libserf-1.so.1
#8 0x00007ffff573b522 in svn_ra_serf__context_run_wait () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#9 0x00007ffff573cd14 in svn_ra_serf__context_run_one () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#10 0x00007ffff572f436 in svn_ra_serf__wait_for_props () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#11 0x00007ffff572f52a in svn_ra_serf__retrieve_props () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#12 0x00007ffff572f585 in svn_ra_serf__fetch_node_props () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#13 0x00007ffff57301eb in svn_ra_serf__fetch_dav_prop () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#14 0x00007ffff57302d3 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#15 0x00007ffff5730735 in svn_ra_serf__get_youngest_revnum () from /usr/lib/x86_64-linux-gnu/libsvn_ra_serf-1.so.1
#16 0x00007ffff7bca27b in svn_client__get_revision_number () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#17 0x00007ffff7bc69af in svn_client__repos_locations () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#18 0x00007ffff7bc6c1f in svn_client__resolve_rev_and_url () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#19 0x00007ffff7bc6dde in svn_client__ra_session_from_path2 () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#20 0x00007ffff7baaeb8 in ?? () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#21 0x00007ffff7bab42a in svn_client_list3 () from /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1
#22 0x00000000004112a2 in ?? ()
#23 0x000000000041cdd2 in ?? ()
#24 0x000000000040764d in ?? ()
#25 0x00007ffff6856ead in __libc_start_main (main=<optimized out>, argc=<optimized out>,
    ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffe2d8) at libc-start.c:244
#26 0x000000000040768d in ?? ()
#27 0x00007fffffffe2d8 in ?? ()
#28 0x000000000000001c in ?? ()
#29 0x0000000000000003 in ?? ()
#30 0x00007fffffffe658 in ?? ()
#31 0x00007fffffffe665 in ?? ()
#32 0x00007fffffffe668 in ?? ()

Remarque concernant la sécurité:
Ce courriel provenant de PostFinance est signé. Vous trouverez d'autres informations à ce sujet sous:
https://www.postfinance.ch/e-signature.
Ne divulguez jamais vos éléments de sécurité à des tiers.

Received on 2015-01-06 14:05:19 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.