You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Joe Orton <jo...@redhat.com> on 2003/07/01 09:52:39 UTC
Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)
On Tue, Jul 01, 2003 at 11:00:02AM +0100, Gareth McCaughan wrote:
> On Monday 30 June 2003 10:49 am, Joe Orton wrote:
>
> [I said:]
> > > > I haven't checked whether the segfault is reproducible; so it's
> > > > conceivable that dodgy hardware could be at fault. I don't have any
> > > > strong reason to believe that my hardware *is* dodgy, though.
> >
> > Gareth, I'd be interested to hear whether this is reproducible or not.
> > It looks like the only reasons zlib should return NULL like this are
> > fairly fatal: out of memory, or library/header version mismatch.
>
> I tried the same operation again and it happened again.
> It didn't fail at the same place in the checkout, but presumably
> the repository has changed a bit in between times. Very
> similar backtrace. I'm not out of disc space, and I don't think
> I'm out of memory. In particular, a gdb process running on
> the core file is "only" about 21M in size.
>
> Anything else I should do?
Can you apply the attached neon patch and see what difference it makes?
Regards,
joe
Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)
Posted by Gareth McCaughan <ga...@pobox.com>.
On Thursday 03 July 2003 11:28 pm, Ben Collins-Sussman wrote:
[I asked:]
> > Um, svn folks, there's a question I should probably have asked
> > earlier. Is it considered antisocial to try to grab the entirety of
> > the svn repository like this? It's rather a lot of bandwidth, after
> > all. If it is, then, er, I've just done it several times in
> > moderately rapid succession. Sorry.
[Ben:]
> We have a lot of bandwidth. The question is, why would you *want* to
> checkout the repository root? A single copy of /trunk is about 15
> megs. Now multiply that by the number of directories in /tags and
> /branches... and um, that's an awfully large tree. :-)
In all honesty? The first time was a mistake. After that, it was
all in the name of bug-hunting. :-)
(Thanks also to Karl for replying in similar vein.)
--
Gareth McCaughan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)
Posted by Ben Collins-Sussman <su...@collab.net>.
Gareth McCaughan <ga...@pobox.com> writes:
> Um, svn folks, there's a question I should probably have asked
> earlier. Is it considered antisocial to try to grab the entirety of
> the svn repository like this? It's rather a lot of bandwidth, after
> all. If it is, then, er, I've just done it several times in
> moderately rapid succession. Sorry.
We have a lot of bandwidth. The question is, why would you *want* to
checkout the repository root? A single copy of /trunk is about 15
megs. Now multiply that by the number of directories in /tags and
/branches... and um, that's an awfully large tree. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)
Posted by kf...@collab.net.
Gareth McCaughan <ga...@pobox.com> writes:
> Um, svn folks, there's a question I should probably have asked earlier.
> Is it considered antisocial to try to grab the entirety of the svn repository
> like this? It's rather a lot of bandwidth, after all. If it is,
> then, er, I've just done it several times in moderately rapid
> succession. Sorry.
I don't think it's a problem. At least, I haven't noticed it
happening :-). (Thanks for asking, though.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)
Posted by Gareth McCaughan <ga...@pobox.com>.
[Joe Orton:]
> > Can you apply the attached neon patch and see what difference it makes?
[me:]
> I'm running the thing again with the patch, and will let
> you know what error code inflateInit2 returned...
OK, here's what happened.
...
A svn/tags/0.14.3/subversion/clients
A svn/tags/0.14.3/subversion/clients/cmdline
A svn/tags/0.14.3/subversion/clients/cmdline/resolve-cmd.c
A svn/tags/0.14.3/subversion/clients/cmdline/proplist-cmd.c
svn: RA layer request failed
svn: could not checkout a file
Program received signal SIGABRT, Aborted.
0x18438bac in kill () from /usr/lib/libc.so.4
(gdb) backtrace
#0 0x18438bac in kill () from /usr/lib/libc.so.4
#1 0x1847a13a in abort () from /usr/lib/libc.so.4
#2 0x18196370 in svn_pool_create (pool=0xc)
at subversion/libsvn_subr/pool.c:62
#3 0x181e8d80 in apr_pool_create_ex (newpool=0xbfbfe454, parent=0x805c018,
abort_fn=0x18196358 <abort_on_pool_failure>, allocator=0x805b200)
at apr_pools.c:831
#4 0x181963d3 in svn_pool_create (pool=0x0)
at subversion/libsvn_subr/pool.c:104
#5 0x1819abdb in svn_utf_utf8_to_native (
utf8_string=0x807e068 "GET request failed for
/repos/svn/!svn/bc/6388/tags/0.14.3/subversion/clients/cmdline/proplist-cmd.c:
Could not initialize zlib: -4 (http://svn.collab.net)", buf=0xbfbfe4d0 "",
bufsize=2048)
at subversion/libsvn_subr/utf.c:510
#6 0x1818f92b in handle_error (err=0x807e050, stream=0x18485e70, fatal=0,
depth=1, parent_apr_err=175002) at subversion/libsvn_subr/error.c:210
#7 0x1818f962 in handle_error (err=0x807e108, stream=0x18485e70, fatal=0,
depth=0, parent_apr_err=0) at subversion/libsvn_subr/error.c:215
#8 0x1818f9a4 in svn_handle_error (err=0x807e108, stream=0x18485e70, fatal=0)
at subversion/libsvn_subr/error.c:226
#9 0x804dc7d in main (argc=3, argv=0xbfbff9f4)
at subversion/clients/cmdline/main.c:1040
#10 0x804ae6a in _start ()
Looking in zlib.h, -4 is Z_MEM_ERROR. And, aha, I realise that
I mis-spoke before when I said that svn didn't seem to be out of
memory on the grounds that the gdb process wasn't large.
$ ps auxww | egrep svn
gjm11 36853 0.0 2.5 21936 6320 p3 I+ 11:24AM 0:00.39
/usr/libexec/elf/gdb /home/gjm11/temp/subversion/bin/svn
gjm11 36854 0.0 9.4 266960 24236 p3 TX 11:24AM 3:57.55
/home/gjm11/temp/subversion/bin/svn checkout http://svn.collab.net/repos/svn
$ ulimit -d
262144
This is all with 0.23, as I said. I seem to remember reading that some
memory leaks and kinda-sorta-not-exactly-leaks have been fixed
since then, so I'll try building something more recent and running
again.
Um, svn folks, there's a question I should probably have asked earlier.
Is it considered antisocial to try to grab the entirety of the svn repository
like this? It's rather a lot of bandwidth, after all. If it is, then, er, I've
just done it several times in moderately rapid succession. Sorry.
--
Gareth McCaughan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)
Posted by Gareth McCaughan <ga...@pobox.com>.
On Tuesday 01 July 2003 10:52 am, Joe Orton wrote:
> > > Gareth, I'd be interested to hear whether this is reproducible or not.
> > > It looks like the only reasons zlib should return NULL like this are
> > > fairly fatal: out of memory, or library/header version mismatch.
...
> Can you apply the attached neon patch and see what difference it makes?
I'll do that. First of all, in the interests of scientific method,
I rebuilt Subversion just as I'd have to in order to apply the
patch, but without applying the patch, and tried again.
This meant that I got debug info in the neon library, so
I can confirm that it's the call to ne_set_error following
inflateInit2 that's the problem, and indeed zmsg is full
of 0s.
I'm running the thing again with the patch, and will let
you know what error code inflateInit2 returned...
--
Gareth McCaughan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org