svn - Bus error - Segmentation fault (core dumped)

Leander

Leander

I keep on getting
Code: 
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:
Code: 
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 ...
Code: 
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 ...
Code: 
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
 
Looks like this is a bug. I recompiled SVN with this options in /etc/make.conf
Code: 
echo "devel_subversion_SET='TOOLS'" >> /etc/make.conf
echo "devel_subversion_UNSET='STATIC'" >> /etc/make.conf
... afterwards I tryid my regualr command again ...
Code: 
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
Code: 
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
 
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.
Click to expand...
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.

Code: 
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?!
 
My current workaround is:
Code: 
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 ;/
 
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.
 
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.
 
Leander said:
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
Click to expand...
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.
 
SirDice said:
Leander said:
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
Click to expand...
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.
Click to expand...
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.
 
Last edited by a moderator:
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)
Code: 
...
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)
Code: 
...
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
Code: 
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
Code: 
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)
 
obsigna said:
Me too.
[...]
Click to expand...

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
 
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.
 
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. ...
Code: 
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 ...
Code: 
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 said:
The fingerprints may change in the future but at least for now there's no reason not to accept them permanently for convinience.
Click to expand...
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@ 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.
Click to expand...
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 ;)
 
Hey, everyone.

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

Code: 
# 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):
    Code: 
    [...]
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
[...]
 
dh58 said:
Hey, everyone.

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

Code: 
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 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):
    Code: 
    [...]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
[...]
Click to expand...


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

Code: 
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
 
Leander said:
Code: 
(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
Click to expand...

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.
 
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.
 
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):

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

Add this to the file and save:

Code: 
--- 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:

Code: 
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.
 
You must log in or register to reply here.
Back
Top