On Sat, Apr 17, 2010 at 10:12:00PM -0700, Aaron Turner wrote:
> Not sure why, but sometimes svnserve segfaults when it runs via
> xinetd. It turns out to be highly repeatable for specific svn
> transactions/commands. Ie:
>
> svn merge -c 2454 . ../../branches/3.4/src
>
> causes the segfault, but another svn command works fine (I had just
> done a number of commits). I've seen it happen with svn update as
> well, so it doesn't seem specific to merge.
>
> Not really sure why, but here is what I'm getting in /var/log/messages:
>
> Apr 18 04:51:59 lagavulin kernel: svnserve[28484]: segfault at
> b786f2fc ip b7503814 sp bfd4b6e0 error 4 in
> libsasl2.so.2.0.22[b74f4000+18000]
> Apr 18 04:51:59 lagavulin xinetd[2797]: EXIT: svn signal=11 pid=28484
> duration=0(sec)
>
> Note the same command works find when svnserve runs as a daemon. I am
> using SASL auth, but 9/10 times it works just fine.
>
> client is OSX/x86 10.6.3, svn v1.6.9 and v1.6.11
> server is Linux (CentOS 5.3/x86), svn v1.6.9
>
> Anyways, problem has seem to gone away after switching to daemon mode,
> so I don't need anyone to fix my problem, but figured a bug report was
> warranted.
If this really is a bug in svnserve, you'll need to compile svnserve with
debug symbols. Then make it crash again and have it dump core. Which is not
the default on Linux but there's some way to turn core-dumping on in /proc
or so. Then send a proper stack trace obtained from the core dump with gdb.
Another thought:
Are all your binaries on the server from CentOS packages, or did you
compile your own? If self-compiled, are you sure that svnserve is
running with the correct set of shared libraries when run from xinetd?
E.g. is it possible that it is running with a different libsasl than
what it was linked to at compile time? This can happen easily on Linux
because the runtime linker will blindly make programs run with "good
enough" shared library versions it finds in its search path. A subtle
shared library mismatch can easily cause segfaults.
The list archives are full of reports from users who ran into this trap.
Stefan
Received on 2010-04-18 10:37:48 CEST