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

Re: svn checkout error

From: <kfogel_at_collab.net>
Date: 2003-11-18 15:42:56 CET

"Robert M.Zigweid" <tigran@tigransoft.org> writes:
> I created a small repository for testing purposes as I'm getting
> myself familiar with subversion, but I've run into a bit of a glitch
> and I'm wondering what it is that I've done wrong. I'm relatively
> certain it's a configuration error that I've made, but I'll be damned
> if I can figure out what it is that I have done wrong.
> svn checkout http://tigransoft/svn
> svn: RA layer request failed
> svn: REPORT request failed on '/svn/!svn/vcc/default'
> svn: REPORT of '/svn/!svn/vcc/default': Could not read status line:
> connection was closed by server. (http://tigransoft)
> Something similar also happens with I svn update
> If I use file:// access this does not occur, which leads me to believe
> that the configuration error may exist in my apache2 configuration,
> but I'm unaware of what I did wrong there. (Limit and LimitExcept
> flags both have what's recommended in the subversion book)
> Any suggestions would be helpful.

Can you run the server under a debugger? See the section "Debugging
the server" in the HACKING file... Well, here it is, to spare you the

Debugging the server

Debugging the ra_dav server

'mod_dav_svn.so' contains the main Subversion server logic; it runs as
a module within mod_dav, which runs as a module within httpd. Since
httpd is probably using dynamic shared modules, you normally won't be
able to set breakpoints in advance when you start Apache in a debugger
such as GDB. Instead, you'll need to start up, then interrupt httpd,
set your breakpoint, and continue:

   % gdb httpd
   (gdb) run -X
   (gdb) break some_func_in_mod_dav_svn
   (gdb) continue

The -X switch is equivalent to -DONE_PROCESS and -DNO_DETACH, which
ensure that httpd runs as a single thread and remains attached to the
tty, respectively. As soon as it starts, it sits and waits for
requests; that's when you hit control-C and set your breakpoint.

You'll probably want to watch Apache's run-time logs


to help determine what might be going wrong and where to set

Debugging the ra_svn client and server, on Unix

Bugs in ra_svn usually manifest themselves with one of the following
cryptic error messages:

  svn: Malformed network data
  svn: Connection closed unexpectedly

(The first message can also mean the data stream was corrupted in
tunnel mode by user dotfiles or hook scripts; see issue 1145.) The
first message generally means you to have to debug the client; the
second message generally means you have to debug the server.

It is easiest to debug ra_svn using a build with --disable-shared
--enable-maintainer-mode. With the latter option, the error message
will tell you exactly what line to set a breakpoint at; otherwise,
look up the line number at the end of marshal.c:vparse_tuple() where
it returns the "Malformed network data" error.

To debug the client, simply pull it up in gdb, set a breakpoint, and
run the offending command:

  % gdb svn
  (gdb) break marshal.c:NNN
  (gdb) run ARGS
  Breakpoint 1, vparse_tuple (list=___, pool=___, fmt=___,
    ap=___) at subversion/libsvn_ra_svn/marshal.c:NNN
  NNN "Malformed network data");

There are several bits of useful information:

  * A backtrace will tell you exactly what protocol exchange is

  * "print *conn" will show you the connection buffer. read_buf,
    read_ptr, and read_end represent the read buffer, which can show
    you the data the marshaller is looking at. (Since read_buf isn't
    generally 0-terminated at read_end, be careful of falsely assuming
    that there's garbage data in the buffer.)

  * The format string determines what the marshaller was expecting to

To debug the server in daemon mode, pull it up in gdb, set a
breakpoint (usually a "Connection closed unexpectedly" error on the
client indicates a "Malformed network data" error on the server,
although it can also indicate a core dump), and run it with the "-X"
option to serve a single connection:

  % gdb svnserve
  (gdb) break marshal.c:NNN
  (gdb) run -X

Then run the offending client command. From there, it's just like
debugging the client.

Debugging the server in tunnel mode is more of a pain. You'll need to
stick something like "{ int x = 1; while (x); }" near the top of
svnserve's main() and put the resulting svnserve in the user path on
the server. Then start an operation, gdb attach the process on the
server, "set x = 0", and step through the code as desired.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 18 16:26:38 2003

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.