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

Valid UTF-8 data followed by invalid UTF-8 sequence and segmentation fault with Subversion 1.3.2 on SuSE 10.1 after zen-update

From: Robert Wenner <robert.wenner_at_atsec.com>
Date: 2006-08-10 03:55:30 CEST


I tried to update my working copy, getting this:

robert@sauerbraten:~/fsp> svn update
Segmentation fault (core dumped)
robert@sauerbraten:~/fsp> svn update
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
robert@sauerbraten:~/fsp> svn cleanup
svn: Valid UTF-8 data
followed by invalid UTF-8 sequence
(hex: 80 96 03 80)
robert@sauerbraten:~/fsp> svn status
svn: Valid UTF-8 data
followed by invalid UTF-8 sequence
(hex: 98 76 03 80)

The core dump is at http://de.geocities.com/robertwenner/core_update.zip

Depending on the repository in which I try this, I get different numbers
in the hex output.

robert@sauerbraten:~/test> svn cleanup
svn: Valid UTF-8 data
followed by invalid UTF-8 sequence
(hex: c8 75 03 80)

robert@sauerbraten:~/eval> svn cleanup
svn: Valid UTF-8 data
(hex: 58)
followed by invalid UTF-8 sequence
(hex: fd 03 80 01)

I googled the error message and found mailing list posts hinting on a
wrong character set. However, I already use UTF8, which was suggested
in these posts.

robert@sauerbraten:~/fsp> echo $LANG

In the issue tracker I found only one item for "core" which was related
to large files and scalability, so I consider it not applicable here.

Next, I tried checking out a new working copy. That results in a seg
The core dump is at http://de.geocities.com/robertwenner/core_checkout.zip
The checkout just created the top level .svn directory.

I built svn from the released 1.3.2 tar ball.

robert@sauerbraten:~/fsp> svn --version
svn, version 1.3.2 (r19776)
   compiled Aug 9 2006, 17:28:55

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

With that command line client I have been working before without problems.
It still works with (some) other repositories (don't see a pattern).

When building, I first ran ./configure only, but it said that SSL support
is not enabled and I ended up with a client that didn't support https://.

Then I tried ./configure --with-ssl and then make and sudo make install.
The output from ./configure is at

I checked the pre-requisites in INSTALL, and they seem fine:

robert@sauerbraten:~> rpm -q autoconf
robert@sauerbraten:~> rpm -q libtool
robert@sauerbraten:~> rpm -q neon
robert@sauerbraten:~> rpm -q python
robert@sauerbraten:~> rpm -q perl

On make check, all tests passed (or were skipped).

I am using SuSE 10.1 and on a second partition I still have a SuSE 9.3
installation with a self-built Subversion 1.3.2. If I explicitly call
that binary, everything is fine:

LD_LIBRARY_PATH=/mnt/suse9/usr/local/lib /mnt/suse9/usr/local/bin/svn
LD_LIBRARY_PATH=/mnt/suse9/usr/local/lib /mnt/suse9/usr/local/bin/svn
At revision 4039.

I remember installing some security patches earlier, but I cannot recall
what patches were installed. I don't find them in the tons of log
messages produced by the zen-updater.

Strangely enough, rebooting solved the problem. I merely post this in case
someone runs into the same problem and for the developers to look into
the cores (if interested).


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 10 03:57:22 2006

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.