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

Re: svnserve hang

From: root <ebay_101011_0x2b_at_yahoo.com>
Date: 2004-02-03 06:29:48 CET

A quick followup --

doing cat of /proc/iomem shows that this address
0xffffe002 is reserved (last entry from output). So
my dilemma is figuring out why it goes there, I
guess...any help is greatly appreciated!

Thanks,
Davis

[root@kafka proc]# cat iomem
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000c8000-000cdfff : Extension ROM
000f0000-000fffff : System ROM
00100000-7ffeffff : System RAM
  00100000-0027555b : Kernel code
  0027555c-00388583 : Kernel data
7fff0000-7fffebff : ACPI Tables
7fffec00-7fffefff : reserved
fd000000-fdffffff : ATI Technologies Inc Rage XL
fe100000-fe10ffff : Broadcom Corporation NetXtreme
BCM5700 Gigabit Ethernet
  fe100000-fe10ffff : tg3
fe110000-fe110fff : ServerWorks OSB4/CSB5 OHCI USB
Controller
  fe110000-fe110fff : usb-ohci
fe111000-fe111fff : ATI Technologies Inc Rage XL
fe500000-fe5fffff : Intel Corp. 82557/8/9 [Ethernet
Pro 100]
  fe500000-fe5fffff : e100
fe700000-fe8fffff : PCI Bus #03
  fe7fe000-fe7fefff : Adaptec AIC-7899P U160/m (#2)
    fe7fe000-fe7fefff : aic7xxx
  fe7ff000-fe7fffff : Adaptec AIC-7899P U160/m
    fe7ff000-fe7fffff : aic7xxx
fe900000-fe900fff : Intel Corp. 82557/8/9 [Ethernet
Pro 100]
  fe900000-fe900fff : e100
feb00000-feb0ffff : Broadcom Corporation NetXtreme
BCM5700 Gigabit Ethernet (#2)
  feb00000-feb0ffff : tg3
fec00000-fec0ffff : reserved
fee00000-fee0ffff : reserved
fff80000-ffffffff : reserved

--- root <ebay_101011_0x2b@yahoo.com> wrote:
>
> --- Philip Martin <philip@codematters.co.uk> wrote:
> > root <ebay_101011_0x2b@yahoo.com> writes:
> >
> > > I've been trying to track down an svnserve hang
> > issue
> > > for some time. The details are below:
> > >
> > > The problem is that a client checkout over the
> > network
> > > (via svn: svn+ssh: or http: or https:) has the
> > problem
> > > that for large repositories it eventually hangs
> on
> > > checkout.
> >
> > Try running the client on the server, i.e. use
> > svn://localhost/ or
> > http://localhost/. That should help to determine
> if
> > it is a network
> > problem.
>
> file:/// checkout works fine. this only happens
> with
> the network whether it be any of the following
> combinations:
>
> https://, svn+ssh://, svn:// with either Win32 CMD
> line svn binary or TortoiseSVN binary.
>
> >
> > > imports and checkins work fine. the system
> > > details and version numbers of all the software
> > are in
> > > a previous email to the list under the same
> > subject
> > > heading.
> >
> > You keep breaking the email threads, which makes
> it
> > awkward when you
> > refer to "a previous email".
>
> sorry - I will try to keep a thread.
>
> >
> > > A recent trial run where the problem
> > > happened is logged below.
> > >
> > > My biggest sticking point is figuring out where
> > the
> > > code jumps to in the gdb backtrace. It seems to
> > jump
> > > off to 0xfffe002 -- where debug symbols do not
> > exist;
> > > It is not apr code.
> >
> > The calling stack frame appears to make an apr
> call,
> > and apr is what
> > calls read/write shown in the strace output.
> >
> > > I completely rebuilt apache and
> > > apr included with apache with debug symbols.
> >
> > Are you sure you built/installed it correctly?
>
> yes, I am positive. ldd on svnserve binary shows
> which libs it uses and it is pointing to the apr
> shared objects that were recently built. I know
> this
> because I did rm -rf /usr/local/apache2 beforehand,
> then did make install for apache..and noted the
> output
> from ldd svnserve shows it is using
> /usr/local/apache2/..
>
> ldd /usr/local/bin/svnserve.bin
> libsvn_repos-1.so.0 =>
> /usr/local/lib/libsvn_repos-1.so.0 (0x40017000)
> libsvn_fs-1.so.0 =>
> /usr/local/lib/libsvn_fs-1.so.0 (0x4002a000)
> libsvn_delta-1.so.0 =>
> /usr/local/lib/libsvn_delta-1.so.0 (0x4004b000)
> libsvn_subr-1.so.0 =>
> /usr/local/lib/libsvn_subr-1.so.0 (0x40053000)
> libsvn_ra_svn-1.so.0 =>
> /usr/local/lib/libsvn_ra_svn-1.so.0 (0x40074000)
> libaprutil-0.so.0 =>
> /usr/local/apache2/lib/libaprutil-0.so.0
> (0x40082000)
> libgdbm.so.2 => /usr/lib/libgdbm.so.2
> (0x400a9000)
> libdb-4.0.so => /lib/libdb-4.0.so
> (0x400b0000)
> libexpat.so.0 => /usr/lib/libexpat.so.0
> (0x40158000)
> libapr-0.so.0 =>
> /usr/local/apache2/lib/libapr-0.so.0 (0x40178000)
> librt.so.1 => /lib/tls/librt.so.1
> (0x40197000)
> libm.so.6 => /lib/tls/libm.so.6 (0x401a9000)
> libcrypt.so.1 => /lib/libcrypt.so.1
> (0x401cc000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x401f9000)
> libpthread.so.0 => /lib/tls/libpthread.so.0
> (0x4020e000)
> libdl.so.2 => /lib/libdl.so.2 (0x4021c000)
> libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2
> (0x40000000)
>
>
> >
> > > (gdb) bt
> > > #0 0xffffe002 in ?? ()
> > > #1 0x4007da8c in writebuf_output
> (conn=0x8055418,
> > > pool=0x80b9cf8,
> > > data=0x404824d7
> > > "\t\206`\234LeWJ,69g\214k[.G\003
> > >
> >
>
\232\023\217MX%t?%\036]-\020\236z``\201\206@\020i\017:K\a-\235C3k@\034*D\207#S\230Ekݮ\e%x\030\205_\031\nY\002%^\215|\023h\021Q\225}fw\213\220\210\200ԢsJ",
> > >
> > > len=98420) at
> > subversion/libsvn_ra_svn/marshal.c:157
> >
> > Look at marshal.c:157, it calls apr_file_write.
> Do
> > you get something
> > like
> >
> > (gdb) p apr_file_write
> > $1 = {apr_status_t (apr_file_t *, const void *,
>
> > apr_size_t *)} 0x10b50 <apr_file_write>
> >
> > or does gdb complain about "no debug info"?
>
> nope, it has debug info, but that is not what its
> calling: here is my output:
>
> (gdb) p apr_file_write
> $1 = {apr_status_t (apr_file_t *, const void *,
> apr_size_t *)} 0x40187e98 <apr_file_write>
>
> (gdb) p apr_file_read
> $2 = {apr_status_t (apr_file_t *, void *, apr_size_t
> *)} 0x40187bc8 <apr_file_read>
>
> (gdb) p readbuf_input
> $3 = {svn_error_t *(svn_ra_svn_conn_t *, char *,
> apr_size_t *)} 0x4007dd52 <readbuf_input>
>
> it always jumps to 0xffffe002 -- it may not even be
> valid which is why it hangs - it is not even close
> to
> the range of addresses where the apr calls live, so
> either it is some other shared library or it is
> jumping off into the weeds for some reason? How can
> I
> figure out if that is library code, which library it
> is, so that I can build it with debug symbols and
> breakpoint there? Also note that 0xffffe002 is no
> where near the range of addresses for any of hte
> shared objects output from the ldd command
> above...what could lead it to leap off a plank here?
>
> on a sidenote -- would ntp (network time protocol)
> affect subversion in any way? I do have ntp
> running,
> but I do not think that this is the problem even if
> a
> time update did occur during a checkout -- simply
> because this problem is 100% repeatable at the same
> point in any repository. That is, if I do a
> checkout
> of reposA it hangs at the same file every time. If
> I
> do a checkout of reposB it hangs at the same file
> every time...etc. Also, it seems to only be hanging
> on binaries -- PDF files, JPG files, compressed HTML
> binaries, etc. Note that it does not ALWAYS hang on
> every binary file -- it will successfully complete
> checkout of a number of JPGs or PDFs, etc., and then
> hang at the same place every time.
>
> >
> > You still haven't shown any gdb/strace output for
> > the client, so I can
> > only guess what the client is doing, I assume it's
> > blocked in a read.
>
> Sorry - client is Win32..I can try to rebuild the
> client binaries. For now, I was just using the
> latest
> builds from tigris.org for CMD line svn and
> TortoiseSVN. I will try to build the clients.
>
>
=== message truncated ===

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 3 06:30:01 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.