"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
trouble:
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
^C
(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
/usr/local/apache2/logs/error_log
/usr/local/apache2/logs/access_log
to help determine what might be going wrong and where to set
breakpoints.
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
failing.
* "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
see.
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