You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dan Christian <dc...@google.com> on 2007/08/09 23:50:10 UTC
svnserve -X doesn't really work
I'm trying to understand some weird write performance in fsfs.
So I fire up svnserve -X --listen-host localhost -r ~/local/svnrepo
However, the client can't really get anywhere. I get:
svn import -m test ~/tmp/margin.el svn://localhost/m6
svn: Can't connect to host 'localhost': Connection refused
Someone suggested that the client is making multiple connections, but
svnserve is exits after the first. Is there any way to make the client use
just the one connection?
How can get a svnserve that works with gdb?
-Dan C
Re: svnserve -X doesn't really work
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/9/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> "Garrett Rooney" <ro...@electricjellyfish.net> writes:
>
> > I've usually used threaded svnserve's with the --foreground switch,
> > i.e. something like:
> >
> > svnserve --foreground -T --listen-host localhost -r ~/local/svnrepo
> >
> > As you've found, -X is largely useless for debugging with a svn client
> > for many commands, it's more useful if you're just typing raw commands
> > in via telnet or something, but that's a pain in the ass for most
> > people.
>
> Threading isn't something you want to introduce when you're
> already debugging something, IMHO ;->. httpd -X can handle
> multiple requests, and I see no reason why -X shouldn't. As Dan
> says, it's currently useless.
>
> Since I know it wasn't always useless, this means libsvn_client's
> bad habit of treating RA connections as cheap and disposable is
> actually getting worse.
Well, threads sure can make things harder, but on the other hand
debugging multiple processes (which is what you'll need for a svn
client command that uses more than one connection simultaneously, and
some of them do) with gdb is just as much of a pain in most cases. So
yeah, making -X work for more than one request in series is fine, but
to make it work for more than one in parallel you'll need either
threads or processes, and threads IMO is easier to deal with in GDB.
At least if you can make the breakpoints actually work ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve -X doesn't really work
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Garrett Rooney" <ro...@electricjellyfish.net> writes:
> I've usually used threaded svnserve's with the --foreground switch,
> i.e. something like:
>
> svnserve --foreground -T --listen-host localhost -r ~/local/svnrepo
>
> As you've found, -X is largely useless for debugging with a svn client
> for many commands, it's more useful if you're just typing raw commands
> in via telnet or something, but that's a pain in the ass for most
> people.
Threading isn't something you want to introduce when you're
already debugging something, IMHO ;->. httpd -X can handle
multiple requests, and I see no reason why -X shouldn't. As Dan
says, it's currently useless.
Since I know it wasn't always useless, this means libsvn_client's
bad habit of treating RA connections as cheap and disposable is
actually getting worse.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve -X doesn't really work
Posted by Dan Christian <dc...@google.com>.
On 8/10/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > If I throw in --enable-all-static, then it won't link. I get lots of
> > errors from libsasl2.a. I'm probably missing static versions of some
> > of the supporting libraries.
>
> Not sure, I haven't tried compiling svn statically in a while. Can
> you turn of sasl support?
Avoiding sasl does the trick. I'm guessing that sasl is poorly
structure and was pulling in things that subversion doesn't link with
like mysql, postgresql.
In case you are curious, a fully static svn is 7.1MB and svnserve is 2.7MB.
I still can't debug what I want. It happens in a thread (even for svn
with a file:// target) and gdb-6.6 isn't breaking at
libsvn_subr/io.c:svn_io_copy_file for me.
-Dan C
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve -X doesn't really work
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/10/07, Dan Christian <dc...@google.com> wrote:
> On 8/9/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > It's possible. I know I've debugged multithreaded svnserve processes
> > with gdb in the past. Are you building a dynamically linked binary or
> > a statically linked on? Statically linked often makes life easier for
> > gdb, in my experience (and we descend into the voodoo debugging where
> > you just try random crap until gdb behaves).
>
> I couldn't figure out how to get subversion to really build statically.
>
> I configure like this, but it still dynamically links libsvn*:
> ./configure --enable-static --disable-shared --prefix=$prefix
> --enable-maintainer-mode --enable-debug --disable-mod-activation
> --disable-subdir-config --enable-experimental-libtool
> --with-apr=${prefix} --with-apr-util=${prefix} --with-neon=$prefix
> --with-serf=$prefix --with-ssl --with-editor=/etc/alternatives/editor
> --without-{apxs,berkeley-db,jdk,jikes,junit,ruby}
>
> If I throw in --enable-all-static, then it won't link. I get lots of
> errors from libsasl2.a. I'm probably missing static versions of some
> of the supporting libraries.
Not sure, I haven't tried compiling svn statically in a while. Can
you turn of sasl support?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve -X doesn't really work
Posted by Dan Christian <dc...@google.com>.
On 8/9/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> It's possible. I know I've debugged multithreaded svnserve processes
> with gdb in the past. Are you building a dynamically linked binary or
> a statically linked on? Statically linked often makes life easier for
> gdb, in my experience (and we descend into the voodoo debugging where
> you just try random crap until gdb behaves).
I couldn't figure out how to get subversion to really build statically.
I configure like this, but it still dynamically links libsvn*:
./configure --enable-static --disable-shared --prefix=$prefix
--enable-maintainer-mode --enable-debug --disable-mod-activation
--disable-subdir-config --enable-experimental-libtool
--with-apr=${prefix} --with-apr-util=${prefix} --with-neon=$prefix
--with-serf=$prefix --with-ssl --with-editor=/etc/alternatives/editor
--without-{apxs,berkeley-db,jdk,jikes,junit,ruby}
If I throw in --enable-all-static, then it won't link. I get lots of
errors from libsasl2.a. I'm probably missing static versions of some
of the supporting libraries.
-Dan C
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve -X doesn't really work
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/9/07, Dan Christian <dc...@google.com> wrote:
> That was my second attempt, but gdb-6.6 doesn't seem to break at my breakpoints.
>
> gdb svnserve (inside emacs)
> (gdb) break main
> Breakpoint 1 at 0x804caca: file subversion/svnserve/main.c, line 304.
> (gdb) run --foreground -d -T --listen-host localhost -r
> /home/dchristian/local/svnrepo
> Starting program:
> /usr/local/google/dchristian/OpenSource/svn/subversion/svnserve
> --foreground -d -T --listen-host localhost -r
> /home/dchristian/local/svnrepo
> Failed to read a valid object file image from memory.
> [Thread debugging using libthread_db enabled]
> [New Thread -1209051456 (LWP 30461)]
> [Switching to Thread -1209051456 (LWP 30461)]
>
> Breakpoint 1, main (argc=8, argv=0xbffff574) at subversion/svnserve/main.c:304
> (gdb) break write
> Breakpoint 2 at 0x42c9c5a0
> (gdb) cont
> Continuing.
> [New Thread -1210766416 (LWP 30543)]
> [Thread -1210766416 (LWP 30543) exited]
> [New Thread -1210766416 (LWP 30549)]
> [Thread -1210766416 (LWP 30549) exited]
> [New Thread -1219159120 (LWP 30550)]
> [New Thread -1210766416 (LWP 30551)]
> [New Thread -1227764816 (LWP 30552)]
> [Thread -1210766416 (LWP 30551) exited]
> [Thread -1227764816 (LWP 30552) exited]
> [Thread -1219159120 (LWP 30550) exited]
>
> Meanwhile the svn import has finished successfully. It either never
> calls write (not likely) or gdb didn't manage to honor the breakpoint.
> In fact, I can't get it to break on 'write' even if I debug svn
> import NEW file://...
Hmm. Maybe try breaking on a svn function instead of a system call?
> It's been a while since I tried to debug threaded programs with gdb.
> I'm probably forgetting something basic. Maybe some kind of dynamic
> loading weirdness.
It's possible. I know I've debugged multithreaded svnserve processes
with gdb in the past. Are you building a dynamically linked binary or
a statically linked on? Statically linked often makes life easier for
gdb, in my experience (and we descend into the voodoo debugging where
you just try random crap until gdb behaves).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve -X doesn't really work
Posted by Dan Christian <dc...@google.com>.
That was my second attempt, but gdb-6.6 doesn't seem to break at my breakpoints.
gdb svnserve (inside emacs)
(gdb) break main
Breakpoint 1 at 0x804caca: file subversion/svnserve/main.c, line 304.
(gdb) run --foreground -d -T --listen-host localhost -r
/home/dchristian/local/svnrepo
Starting program:
/usr/local/google/dchristian/OpenSource/svn/subversion/svnserve
--foreground -d -T --listen-host localhost -r
/home/dchristian/local/svnrepo
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1209051456 (LWP 30461)]
[Switching to Thread -1209051456 (LWP 30461)]
Breakpoint 1, main (argc=8, argv=0xbffff574) at subversion/svnserve/main.c:304
(gdb) break write
Breakpoint 2 at 0x42c9c5a0
(gdb) cont
Continuing.
[New Thread -1210766416 (LWP 30543)]
[Thread -1210766416 (LWP 30543) exited]
[New Thread -1210766416 (LWP 30549)]
[Thread -1210766416 (LWP 30549) exited]
[New Thread -1219159120 (LWP 30550)]
[New Thread -1210766416 (LWP 30551)]
[New Thread -1227764816 (LWP 30552)]
[Thread -1210766416 (LWP 30551) exited]
[Thread -1227764816 (LWP 30552) exited]
[Thread -1219159120 (LWP 30550) exited]
Meanwhile the svn import has finished successfully. It either never
calls write (not likely) or gdb didn't manage to honor the breakpoint.
In fact, I can't get it to break on 'write' even if I debug svn
import NEW file://...
It's been a while since I tried to debug threaded programs with gdb.
I'm probably forgetting something basic. Maybe some kind of dynamic
loading weirdness.
-Dan C
On 8/9/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 8/9/07, Dan Christian <dc...@google.com> wrote:
> > I'm trying to understand some weird write performance in fsfs.
> >
> > So I fire up svnserve -X --listen-host localhost -r ~/local/svnrepo
> >
> > However, the client can't really get anywhere. I get:
> > svn import -m test ~/tmp/margin.el svn://localhost/m6
> > svn: Can't connect to host 'localhost': Connection refused
> >
> > Someone suggested that the client is making multiple connections, but
> > svnserve is exits after the first. Is there any way to make the client use
> > just the one connection?
> >
> > How can get a svnserve that works with gdb?
>
> I've usually used threaded svnserve's with the --foreground switch,
> i.e. something like:
>
> svnserve --foreground -T --listen-host localhost -r ~/local/svnrepo
>
> As you've found, -X is largely useless for debugging with a svn client
> for many commands, it's more useful if you're just typing raw commands
> in via telnet or something, but that's a pain in the ass for most
> people.
>
> -garrett
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve -X doesn't really work
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/9/07, Dan Christian <dc...@google.com> wrote:
> I'm trying to understand some weird write performance in fsfs.
>
> So I fire up svnserve -X --listen-host localhost -r ~/local/svnrepo
>
> However, the client can't really get anywhere. I get:
> svn import -m test ~/tmp/margin.el svn://localhost/m6
> svn: Can't connect to host 'localhost': Connection refused
>
> Someone suggested that the client is making multiple connections, but
> svnserve is exits after the first. Is there any way to make the client use
> just the one connection?
>
> How can get a svnserve that works with gdb?
I've usually used threaded svnserve's with the --foreground switch,
i.e. something like:
svnserve --foreground -T --listen-host localhost -r ~/local/svnrepo
As you've found, -X is largely useless for debugging with a svn client
for many commands, it's more useful if you're just typing raw commands
in via telnet or something, but that's a pain in the ass for most
people.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org