# svn - Bus error - Segmentation fault (core dumped)



## Leander (May 27, 2014)

I keep on getting

```
45812 Bus error               (core dumped) svn checkout ${SRC_SVN_URL} /usr/src --non-interactive --trust-server-cert --quiet
```
since approximately a week when I try to sync the FreeBSD sources. I wonder what has changed / why this is happening ... it always worked out perfectly and my command hasn't changed.

Here is the full command I use to sync sources:

```
SVN_Server="https://svn0.eu.FreeBSD.org"
FreeBSD_Version="$(uname -r | sed -E 's|(.*)-.*|\1|')"
SRC_SVN_URL="${SVN_Server}/base/releng/${FreeBSD_Version}/"
svn checkout ${SRC_SVN_URL} /usr/src --non-interactive --trust-server-cert --quiet > /dev/null 2>&1 &
```


Also I get a 'Service unavailable' message from console after command has been initiated ...

```
svn checkout https://svn0.eu.FreeBSD.org/base/releng/10.0 /usr/src --non-interactive --trust-server-cert
Service unavailableA    /usr/src/secure
A    /usr/src/secure/lib
A    /usr/src/secure/lib/libssh
[...]
A    /usr/src/contrib/llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
A    /usr/src/contrib/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
Segmentation fault (core dumped)
```

... svn always interrupts at a different point ...

```
svn checkout https://svn0.eu.FreeBSD.org/base/releng/10.0 /usr/src --non-interactive --trust-server-cert
Service unavailableA    /usr/src/secure
A    /usr/src/secure/lib
A    /usr/src/secure/lib/libssh
[...]
A    /usr/src/usr.sbin/pwd_mkdb/pwd_mkdb.8
A    /usr/src/usr.sbin/bootparamd/bootparamd/Makefile
Segmentation fault (core dumped)
```

Any idea what this means / how to fix this?
Thanks


----------



## Leander (May 27, 2014)

Looks like this is a bug. I recompiled SVN with this options in /etc/make.conf

```
echo "devel_subversion_SET='TOOLS'" >> /etc/make.conf
echo "devel_subversion_UNSET='STATIC'" >> /etc/make.conf
```
... afterwards I tryid my regualr command again ...

```
svn checkout ${SRC_SVN_URL} /usr/src --non-interactive --trust-server-cert
```
... and "Service unavailable" disappeared. But it still doesn't run through all the way smoothly yet. I still get an error

```
svn checkout ${SRC_SVN_URL} /usr/src --non-interactive --trust-server-cert
A    /usr/src/bin
A    /usr/src/bin/dd
[...]
A    /usr/src/crypto/heimdal/lib/roken/strncasecmp.c
A    /usr/src/crypto/heimdal/lib/roken/tsearch.c
Bus error (core dumped)
```
Has any one an idea what could possibly cause this error?
Thanks


----------



## SirDice (May 27, 2014)

Both options are turned off by default. That probably has a reason. 

You don't need an account to report a bug: Submit a FreeBSD problem report


----------



## Leander (May 27, 2014)

Sorry, you may have missed my post edit. The problem isn't fixed yet.


			
				SirDice said:
			
		

> Both options are turned off by default. That probably has a reason.


Originally I've compiled it with its defaults plus I set STATIC. Now I've tried three ways

First way (with STATIC):
`echo "devel_subversion_SET='STATIC'" >> /etc/make.conf`

Second way (with TOOLS):
`echo "devel_subversion_SET='TOOLS'" >> /etc/make.conf`

Third way (default):
`echo "" >> /etc/make.conf`

The "Unavailable Service" message has disappeared after STATIC was unset. Yet nothing of this has helped svn to perform as regular. It still breaks randomly in between its action of syncing the sources.


```
svn checkout ${SRC_SVN_URL} /usr/src --non-interactive --trust-server-cert
A    /usr/src/bin
A    /usr/src/bin/dd
[...]
A    /usr/src/contrib/libstdc++/include/c_compatibility/errno.h
A    /usr/src/contrib/libstdc++/include/c_std/std_cstdlib.h
Segmentation fault (core dumped)
```

Please note, that I get randomly two different errors:

Segmentation fault (core dumped)
Bus error (core dumped)
My RAM is brand new and has ECC. Otherwhise everything runs very smoothly - so what does this mean??
It looks like subversion is broken?!


----------



## Leander (May 27, 2014)

My current workaround is:

```
svn checkout ${SRC_SVN_URL} /usr/src --non-interactive --trust-server-cert
A    /usr/src/bin
A    /usr/src/bin/dd
[...]
A    /usr/src/crypto/heimdal/lib/roken/strncasecmp.c
A    /usr/src/crypto/heimdal/lib/roken/tsearch.c
Bus error (core dumped)

svn cleanup /usr/src

svn update /usr/src
[...]
A    /usr/src/usr.sbin/makefs/ffs/mkfs.c
A    /usr/src/usr.sbin/rip6query/Makefile
 U   /usr/src
Aktualisiert zu Revision 266746.

Pfad: /usr/src
Wurzelpfad der Arbeitskopie: /usr/src
URL: https://svn0.eu.freebsd.org/base/releng/10.0
Relative URL: ^/releng/10.0
Basis des Projektarchivs: https://svn0.eu.freebsd.org/base
UUID des Projektarchivs: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 266746
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: delphij
Letzte geänderte Rev: 265987
Letztes Änderungsdatum: 2014-05-14 01:22:28 +0200 (Mi, 14. Mai 2014)
```
This fetches the expected sources BUT it is not a solution ;/


----------



## kpa (May 27, 2014)

I haven't seen any such errors with SVN and I have used it for a very long time. I'd suggest taking a look at CPU temperatures and voltages on your system.


----------



## Leander (May 27, 2014)

I monitor my CPU temperatures - it is below 30C in each core - BIOS tells me 5C more but this would still be more than fine. It is a brand new SuperMicro X10SAT mainboard with Intel(R) Xeon(R) CPU E3-1245 v3 @ 3.40GHz. RAM is also more than enough (32GB) ...
Those errors are also new to me - I've noticed them since the past week.


----------



## SirDice (May 27, 2014)

Leander said:
			
		

> First way (with STATIC):
> `echo "devel_subversion_SET='STATIC'" >> /etc/make.conf`
> 
> Second way (with TOOLS):
> ...


This doesn't "reset" your previous settings, it simply adds an empty line to /etc/make.conf. I have a feeling you now have a bunch of _SET and _UNSET variables in your make.conf, that's certainly going to cause problems. Use `make rmconfig` and `make config` to reset/set options. And clean up /etc/make.conf.


----------



## Leander (May 27, 2014)

SirDice said:
			
		

> Leander said:
> 
> 
> 
> ...


Thanks @SirDice. Sorry, I wasn't detailed enough. I made sure my /etc/make.conf was empty everytime before I tried again. I also used `make rmconfig` and `make config` to ensure /etc/make.conf isn't interfering with previous settings. So this is not the problem. The issue still exists.


[EDIT]: For further reference, my /etc/make.conf is currently entirely empty. And as mentioned before - it still results in the same two errors with the initial `svn checkout ...` command. Only the workaround makes it possible to load entire sources into /usr/src.


----------



## obsigna (May 27, 2014)

Me too.

This occurred on two different machines today:

`cd /usr/ports; svn update`

1. machine FreeBSD 9.2-RELEASE-p6 - amd64, svn version 1.8.9 (r1591380)

```
...
U    LEGAL
U    japanese/mozc-server/Makefile
A    japanese/canna-lib/files/patch-dic-phono-newjis.kpdef
U    japanese/font-ume/Makefile
U    japanese/kterm/Makefile
A    japanese/canna-server/files/patch-dic-phono-newjis.kpdef
U    japanese/groff/Makefile
bash: line 1: 39624 Bus error: 10           (core dumped) svn update
```

2. machine FreeBSD 10.0-RELEASE-p3 - amd64, svn version 1.8.8 (r1568071)

```
...
U    devel/msp430-libc/Makefile
U    devel/p5-Tree-Node/Makefile
A    devel/lua-alien/files/patch-src__alien.c
U    devel/libuv/Makefile
A    devel/p5-Test-Net-LDAP/Makefile
U    devel/p5-Term-Query/Makefile
U    devel/lutok/pkg-plist
U    devel/p5-strictures/distinfo
U    devel/geany-plugin-spellcheck/Makefile
U    devel/p5-Module-Install-Template/Makefile
U    devel/p5-Data-HashArray/Makefile
U    devel/p5-Agent/Makefile
Segmentation fault (core dumped)
```

Two different FreeBSD releases with two different svn versions, all of which worked a few days ago. Perhaps something is spoiled at the repository sites?

FreeBSD 9 `cd /usr/ports; svn info`

```
Path: .
Working Copy Root Path: /usr/ports
URL: https://svn0.us-east.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: https://svn0.us-east.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 355524
Node Kind: directory
Schedule: normal
Last Changed Author: grembo
Last Changed Rev: 354937
Last Changed Date: 2014-05-23 10:25:23 -0300 (Fri, 23 May 2014)
```

FreeBSD 10 `cd /usr/ports; svn info`

```
Path: .
Working Copy Root Path: /usr/ports
URL: https://svn0.eu.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: https://svn0.eu.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 355524
Node Kind: directory
Schedule: normal
Last Changed Author: rakuco
Last Changed Rev: 353034
Last Changed Date: 2014-05-05 14:30:01 -0300 (Mon, 05 May 2014)
```


----------



## Leander (May 27, 2014)

obsigna said:
			
		

> Me too.
> [...]



Ha! Thank you ;

So according to your confirmation it is more and more sure that this is not a hardware related problem but a bug somewhere in the software or in the SVN repo. I was about to remove RAM DIMM by RAM DIMM ... then a memory test on each ... and in an additional step, also putting the entire FreeBSD OS on another HDD in order to debug where this crap is coming from. You saved my evening 

Anyway, how to continue here? Any idea who to inform or what to debug any further?

Kind regards


----------



## kpa (May 27, 2014)

Try the builtin svnlite if you're on FreeBSD 10, if it doesn't exhibit the problem then this is a problem with the port version or one of its dependencies. Are you both on amd64? My system is i386.


----------



## wblock@ (May 27, 2014)

Can't recall why, but this has happened to me.  Rebuilding devel/subversion and the ports it depended on cured it... I think.  It's been a while.


----------



## Leander (May 27, 2014)

I can report, that svnlite(1) does perform just fine. I can confirm, that the issue is only related to devel/subversion - so the repository is fine.
I didn't know svnlite(1) exists but I want so switch over to it. Unfortunately svnlite(1) has a bug related to https certs. While eg. ...

```
svnlite checkout https://svn0.eu.FreeBSD.org/base/releng/10.0/ /usr/src
Error validating server certificate for 'https://svn0.eu.freebsd.org:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: svnmir.bme.FreeBSD.org
 - Valid: from Jun 29 12:24:17 2013 GMT until Jun 29 12:24:17 2015 GMT
 - Issuer: clusteradm, FreeBSD.org, (null), CA, US (clusteradm@FreeBSD.org)
 - Fingerprint: 39:B0:53:35:CE:60:C7:BB:00:54:96:96:71:10:94:BB:CE:1C:07:A7
(R)eject, accept (t)emporarily or accept (p)ermanently? t
A    /usr/src/lib
A    /usr/src/lib/libnetbsd
[...]
```
 ... performs just fine ...

```
svnlite checkout https://svn0.eu.FreeBSD.org/base/releng/10.0/ /usr/src --non-interactive --trust-server-cert
svn: E230001: Unable to connect to a repository at URL 'https://svn0.eu.freebsd.org/base/releng/10.0'
svn: E230001: Server SSL certificate untrusted
```
 ... won't work.

Unfortunately I need the combination --non-interactive --trust-server-cert in my unattended scripts. Is there a way to fix this or am I simply just missing something?
Thanks


----------



## kpa (May 27, 2014)

I have accepted the certificate permanently after verifying it against the list of known mirrors and their fingerprints:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn.html

The fingerprints may change in the future but at least for now there's no reason not to accept them permanently for convenience.


----------



## Leander (May 27, 2014)

kpa said:
			
		

> The fingerprints may change in the future but at least for now there's no reason not to accept them permanently for convinience.


I also don't see a problem in not trusting them - yet my scripts are there to install and configure further software on -new- FreeBSD installations. The more user interaction the script requires the more bad it is. But I guess saving the fingerprint of each potential HTTPS SVN repository into ~/.subversion/auth/ is for now at least an acceptable workaround. Is there a special reason why svnlite(1) doesn't accept --non-interactive --trust-server-cert as expected, or is this really a bug?


----------



## wblock@ (May 27, 2014)

`svnlite` is a trimmed-down version, it may not have whatever does HTTPS in the full version.  Maybe www/serf?  But rebuilding that, security/openssl, devel/apr1, databases/sqlite3, then devel/subversion might get the main one to work.


----------



## Leander (May 28, 2014)

wblock@ said:
			
		

> `svnlite` is a trimmed-down version, it may not have whatever does HTTPS in the full version.  Maybe www/serf?  But rebuilding that, security/openssl, devel/apr1, databases/sqlite3, then devel/subversion might get the main one to work.


Well, the name is telling already about its lite version of SVN - so this is kind of what I expected. But of the given switches, which are originally taken of devel/subversion like eg. --non-interactive --trust-server-cert I

expect them to work the very same as of devel/subversion
expect them to work as described in `svnlite help`
Otherwise I call this a bug  Or how would you call it if you first have to manually trust the cert once permanently before --trust-server-cert is doing its job


----------



## Leander (May 28, 2014)

Correspondending FreeBSD problem report:

http://www.freebsd.org/cgi/query-pr.cgi?pr=190331


----------



## dh58 (May 28, 2014)

Hey, everyone.

If you're experiencing segfaults / bus errors with svn 1.8.x on FreeBSD, please do the following:


```
# clear any subversion options from /etc/make.conf ideally, but otherwise state your changes
cd /usr/ports/devel/subversion
make deinstall
make clean
make rmconfig
make WITH_DEBUG=yes install                                # accept default options ideally, but otherwise state your changes
cd /usr/ports/www/serf
make deinstall
make clean
make rmconfig
make WITH_DEBUG=yes install                                # accept default options ideally, but otherwise state your changes
```

Then run your usual SVN command. When you get your segfault / bus error, you'll probably get a core file named svn.core. Post these details:


 The command you're running -- e.g., `svn co [...]`
 The output of `svn --version -v`
The output of `grep http-max ~/.subversion/servers`
The output of `gdb svn svn.core`. Type `bt` at the gdb prompt and post that output too. Sample gdb output (I've snipped this for brevity, but please post your output in full): 

```
[...]
Core was generated by `svn'.
Program terminated with signal 11, Segmentation fault.
#0  0x28194066 in window_handler (window=0xbfbfdd50, baton=0x29139058)
    at subversion/libsvn_wc/update_editor.c:977
977       svn_wc__db_t *db = fb->edit_baton->db;
(gdb) bt
#0  0x28194066 in window_handler (window=0xbfbfdd50, baton=0x29139058)
    at subversion/libsvn_wc/update_editor.c:977
#1  0x282d6442 in handle_fetch (request=0x28b32ba0, response=0x28fdf5a0, 
    handler_baton=0x28dfa058, pool=0x2959d018)
    at subversion/libsvn_ra_serf/update.c:1206
[...]
```


----------



## Leander (May 28, 2014)

dh58 said:
			
		

> Hey, everyone.
> 
> If you're experiencing segfaults / bus errors with svn 1.8.9 on FreeBSD, please do the following:
> 
> ...




Thanks for your reply. I did what you asked. Below are the results:


```
echo "" > /etc/make.conf

cd /usr/ports/devel/subversion
make deinstall
make clean
make rmconfig
make WITH_DEBUG=yes install

cd /usr/ports/www/serf
make deinstall
make clean
make rmconfig
make WITH_DEBUG=yes install

rm -r /usr/src
mkdir -p -m 0755 /usr/src
chown -R root:wheel /usr/src

svn checkout https://svn0.eu.FreeBSD.org/base/releng/10.0/ /usr/src --non-interactive --trust-server-cert
A    /usr/src/tools
A    /usr/src/tools/debugscripts
[...]
A    /usr/src/lib/libkse/thread/thr_mutexattr_destroy.c
A    /usr/src/lib/libkse/thread/thr_accept.c
Segmentation fault (core dumped)



svn --version -v
svn, Version 1.8.9 (r1591380)
   übersetzt am May 28 2014, um 12:12:18 auf amd64-portbld-freebsd10.0

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

Die folgenden ZugriffsModule (ZM) für Projektarchive stehen zur Verfügung:

* ra_svn : Modul zum Zugriff auf ein Projektarchiv über das svn-Netzwerkprotokoll
  - behandelt Schema »svn«
* ra_local : Modul zum Zugriff auf ein Projektarchiv auf der lokalen Festplatte
  - behandelt Schema »file«
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.5
  - behandelt Schema »http«
  - behandelt Schema »https«

Systeminformationen:

* ausgeführt auf amd64-unknown-freebsd10.0
  - FreeBSD 10.0-RELEASE
* eingebundene Abhändigleiten:
  - APR 1.5.1 (compiled with 1.5.1)
  - APR-Util 1.5.3 (compiled with 1.5.3)
  - SQLite 3.8.4.3 (compiled with 3.8.4.3)







gdb svn svn.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `svn'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libsvn_client-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_client-1.so.0
Reading symbols from /usr/local/lib/libsvn_wc-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_wc-1.so.0
Reading symbols from /usr/local/lib/libsvn_ra-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_ra-1.so.0
Reading symbols from /usr/local/lib/libsvn_diff-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_diff-1.so.0
Reading symbols from /usr/local/lib/libsvn_ra_local-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_ra_local-1.so.0
Reading symbols from /usr/local/lib/libsvn_repos-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_repos-1.so.0
Reading symbols from /usr/local/lib/libsvn_fs-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_fs-1.so.0
Reading symbols from /usr/local/lib/libsvn_fs_fs-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_fs_fs-1.so.0
Reading symbols from /usr/local/lib/libsvn_fs_util-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_fs_util-1.so.0
Reading symbols from /usr/local/lib/libsvn_ra_svn-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_ra_svn-1.so.0
Reading symbols from /usr/local/lib/libsvn_ra_serf-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_ra_serf-1.so.0
Reading symbols from /usr/local/lib/libserf-1.so.1...done.
Loaded symbols for /usr/local/lib/libserf-1.so.1
Reading symbols from /usr/local/lib/libsvn_delta-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_delta-1.so.0
Reading symbols from /usr/local/lib/libsvn_subr-1.so.0...done.
Loaded symbols for /usr/local/lib/libsvn_subr-1.so.0
Reading symbols from /usr/local/lib/libsqlite3.so.8...done.
Loaded symbols for /usr/local/lib/libsqlite3.so.8
Reading symbols from /usr/local/lib/libaprutil-1.so.5...done.
Loaded symbols for /usr/local/lib/libaprutil-1.so.5
Reading symbols from /usr/local/lib/libexpat.so.6...done.
Loaded symbols for /usr/local/lib/libexpat.so.6
Reading symbols from /usr/local/lib/libapr-1.so.5...done.
Loaded symbols for /usr/local/lib/libapr-1.so.5
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/lib/libssl.so.7...done.
Loaded symbols for /usr/lib/libssl.so.7
Reading symbols from /lib/libcrypto.so.7...done.
Loaded symbols for /lib/libcrypto.so.7
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/lib/libmagic.so.4...done.
Loaded symbols for /usr/lib/libmagic.so.4
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libdb-4.8.so.0...done.
Loaded symbols for /usr/local/lib/libdb-4.8.so.0
Reading symbols from /usr/local/lib/libgdbm.so.4...done.
Loaded symbols for /usr/local/lib/libgdbm.so.4
Reading symbols from /usr/lib/i18n/libiconv_std.so.4...done.
Loaded symbols for /usr/lib/i18n/libiconv_std.so.4
Reading symbols from /usr/lib/i18n/libUTF8.so.4...done.
Loaded symbols for /usr/lib/i18n/libUTF8.so.4
Reading symbols from /usr/lib/i18n/libmapper_none.so.4...done.
Loaded symbols for /usr/lib/i18n/libmapper_none.so.4
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000000080527f028 in ?? ()
[New Thread 805006400 (LWP 100163/svn)]
(gdb) bt
#0  0x000000080527f028 in ?? ()
#1  0x0000000800b79a47 in window_handler (window=0x7fffffffbe80, baton=0x80527f0a0) at subversion/libsvn_wc/update_editor.c:981
#2  0x0000000801f19fff in handle_fetch (request=0x805fca038, response=0x805e355b8, handler_baton=0x8063456a8, pool=0x80529d028) at subversion/libsvn_ra_serf/update.c:1206
#3  0x0000000801f1ee5a in handle_response (request=0x805fca038, response=0x805e355b8, handler=0x806345710, serf_status=0x7fffffffbffc, scratch_pool=0x80529d028) at subversion/libsvn_ra_serf/util.c:2231
#4  0x0000000801f1e19c in handle_response_cb (request=0x805fca038, response=0x805e355b8, baton=0x806345710, scratch_pool=0x80529d028) at subversion/libsvn_ra_serf/util.c:2264
#5  0x0000000802135ef5 in serf__process_connection (conn=0x80536b028, events=1) at outgoing.c:938
#6  0x0000000802135141 in serf_event_trigger (s=<value optimized out>, serf_baton=<value optimized out>, desc=0x99e) at context.c:226
#7  0x0000000802135259 in serf_context_run (ctx=<value optimized out>, duration=<value optimized out>, pool=0x99e) at context.c:300
#8  0x0000000801f14686 in finish_report (report_baton=0x8050b2ad0, pool=0x8050af028) at subversion/libsvn_ra_serf/update.c:2832
#9  0x0000000800b0e1c6 in svn_wc_crawl_revisions5 (wc_ctx=0x8050308b8, local_abspath=0x8050af120 "/usr/src", reporter=0x80212b270, report_baton=0x8050b2ad0, restore_files=1, depth=svn_depth_unknown, honor_depth_exclude=1, depth_compatibility_trick=0, use_commit_times=0, 
    cancel_func=0x429600 <svn_cl__check_cancel>, cancel_baton=0x0, notify_func=0x41dc40 <notify>, notify_baton=0x8050309d8, scratch_pool=0x8050af028) at subversion/libsvn_wc/adm_crawler.c:845
#10 0x00000008008e6ee8 in update_internal (result_rev=0x0, conflicted_paths=0x8050b0590, local_abspath=0x8050af120 "/usr/src", anchor_abspath=0x8050b0660 "/usr/src", revision=0x7fffffffcb18, depth=svn_depth_unknown, depth_is_sticky=0, ignore_externals=0, 
    allow_unver_obstructions=0, adds_as_modification=1, timestamp_sleep=0x7fffffffcd6c, notify_summary=1, ctx=0x805030800, pool=0x8050af028) at subversion/libsvn_client/update.c:459
#11 0x00000008008e5ed3 in svn_client__update_internal (result_rev=0x0, local_abspath=0x8050af120 "/usr/src", revision=0x7fffffffce50, depth=svn_depth_unknown, depth_is_sticky=1, ignore_externals=0, allow_unver_obstructions=0, adds_as_modification=1, make_parents=0, innerupdate=0, 
    timestamp_sleep=0x7fffffffcd6c, ctx=0x805030800, pool=0x8050af028) at subversion/libsvn_client/update.c:595
#12 0x000000080087a473 in svn_client__checkout_internal (result_rev=0x0, url=0x8050ad588 "https://svn0.eu.freebsd.org/base/releng/10.0", local_abspath=0x8050af120 "/usr/src", peg_revision=0x7fffffffce40, revision=0x7fffffffce50, depth=svn_depth_unknown, ignore_externals=0, 
    allow_unver_obstructions=0, timestamp_sleep=0x7fffffffcd6c, ctx=0x805030800, pool=0x8050af028) at subversion/libsvn_client/checkout.c:160
#13 0x000000080087a639 in svn_client_checkout3 (result_rev=0x0, URL=0x8050ad588 "https://svn0.eu.freebsd.org/base/releng/10.0", path=0x8050ad660 "/usr/src", peg_revision=0x7fffffffce40, revision=0x7fffffffce50, depth=svn_depth_unknown, ignore_externals=0, 
    allow_unver_obstructions=0, ctx=0x805030800, pool=0x8050af028) at subversion/libsvn_client/checkout.c:189
#14 0x00000000004098e6 in svn_cl__checkout (os=0x80502f520, baton=0x7fffffffd2d8, pool=0x80502f028) at subversion/svn/checkout-cmd.c:161
#15 0x000000000042ca36 in sub_main (argc=6, argv=0x7fffffffd5b8, pool=0x80502f028) at subversion/svn/svn.c:2878
#16 0x00000000004296dc in main (argc=6, argv=0x7fffffffd5b8) at subversion/svn/svn.c:2973
(gdb)
```

Let me know whether you need more information.

Kind Regards


----------



## dh58 (May 28, 2014)

Leander said:
			
		

> ```
> (gdb) bt
> #0  0x000000080527f028 in ?? ()
> #1  0x0000000800b79a47 in window_handler (window=0x7fffffffbe80, baton=0x80527f0a0) at subversion/libsvn_wc/update_editor.c:981
> ...



Aha! Yeah, same crash as mine. Here's my post to the subversion-users mailing list a few days ago:

http://mail-archives.apache.org/mod...7dfbf481a33801ad85f610ff620f@openmailbox.org>

One of the developers may have identified the problem:

http://mail-archives.apache.org/mod...x/<00b401cf78df$8123f050$836bd0f0$@qqmail.nl>

In the last few hours, he's made a few serf commits (r2360 and r2361) that seem related to the problem: 

http://code.google.com/p/serf/source/list

I'm awaiting confirmation that they are indeed related. If they are, I'm not sure how long it will be before the www/serf 
maintainer (apache@freebsd.org) pushes them through. With impersonal @freebsd.org maintainer email addresses (apache@, gnome@, etc.), my emails 
seem to have disappeared into the void to no avail in the past. I'll probably be patching manually.


----------



## wblock@ (May 28, 2014)

The maintainer for www/serf is just the Apache group at FreeBSD, not an individual.  If there is an update and you can't get anyone's attention, there is #bsdports on EFnet for IRC, or the freebsd-ports mailing list.


----------



## dh58 (May 28, 2014)

For those getting segfaults / bus errors with SVN 1.8.x, here's a fix I've put together using Bert Huijben's recent Serf commits (it resolves the segfaults for me):


```
cd /usr/ports/www/serf
make deinstall
make clean
vi files/patch-outgoing.c
```

Add this to the file and save:


```
--- outgoing.c.orig	2014-00-00 00:00:00.000000000 +0000
+++ outgoing.c	2014-00-00 00:00:00.000000000 +0000
@@ -23,6 +23,13 @@
 
 #include "serf_private.h"
 
+/* Some implementations -like Windows- report some hangup errors via a
+   different event than the specific HUP event. */
+#define APR_STATUS_IMPLIES_HANGUP(status)               \
+        (APR_STATUS_IS_ECONNRESET(status) ||            \
+         APR_STATUS_IS_ECONNABORTED(status) ||          \
+         status == SERF_ERROR_REQUEST_LOST)
+
 /* cleanup for sockets */
 static apr_status_t clean_skt(void *data)
 {
@@ -922,8 +929,10 @@
                                             request->handler_baton,
                                             pool);
 
-        if (SERF_BUCKET_READ_ERROR(status)) {
-            /* Report the request as 'died'/'cancelled' to the application */
+        if (SERF_BUCKET_READ_ERROR(status) && !APR_STATUS_IMPLIES_HANGUP(status)) {
+              /* Report the request as 'died'/'cancelled' to the application,
+               but only if our caller doesn't handle this status specifically,
+               with something like a retry */
             (void)(*request->handler)(request,
                                       NULL,
                                       request->handler_baton,
@@ -1128,10 +1137,12 @@
 
         /* Some systems will not generate a HUP poll event so we have to
          * handle the ECONNRESET issue and ECONNABORT here.
+         *
+         * ### Update similar code in handle_response() if this condition
+         *     changes, or requests will get lost and/or accidentally reported
+         *     cancelled.
          */
-        if (APR_STATUS_IS_ECONNRESET(status) ||
-            APR_STATUS_IS_ECONNABORTED(status) ||
-            status == SERF_ERROR_REQUEST_LOST) {
+        if (APR_STATUS_IMPLIES_HANGUP(status)) {
             /* If the connection had ever been good, be optimistic & try again.
              * If it has never tried again (incl. a retry), fail.
              */
```

Then:


```
make install clean
# test out svn now
```

Let me know whether it does the trick. If all seems well, I'll submit it to freebsd-ports and the maintainer address.


----------

