You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gareth McCaughan <ga...@pobox.com> on 2003/06/28 08:45:31 UTC
Segfault in "svn checkout" (svn client 0.23; server at collab.net)
$ svn co http://svn.collab.net/repos/svn
... lots and lots of "A <filename>" lines , ending with:
A svn/branches/fs-schema-changes/www/webdav-usage.html
A svn/branches/fs-schema-changes/www/project_nav.html
A svn/branches/fs-schema-changes/www/project_status.html
Segmentation fault (core dumped)
$ gdb /usr/local/bin/svn svn.core
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called
at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line
933 in fill_symbuf
Core was generated by `svn'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libsvn_client-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_wc-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_ra-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_diff-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_ra_local-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_repos-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_fs-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_delta-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_ra_dav-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_ra_svn-1.so.0...done.
Reading symbols from /usr/local/lib/libsvn_subr-1.so.0...done.
Reading symbols from /usr/local/lib/libaprutil-0.so.9...done.
Reading symbols from /usr/local/lib/libdb4.so.0...done.
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Reading symbols from /usr/local/lib/libapr-0.so.9...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/local/lib/libneon.so.23...done.
Reading symbols from /usr/lib/libssl.so.3...done.
Reading symbols from /usr/lib/libcrypto.so.3...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/local/lib/libexpat.so.4...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x284b77f8 in vfprintf () from /usr/lib/libc.so.4
(gdb) backtrace
#0 0x284b77f8 in vfprintf () from /usr/lib/libc.so.4
#1 0x28481e24 in vsnprintf () from /usr/lib/libc.so.4
#2 0x282e5a81 in ne_set_error () from /usr/local/lib/libneon.so.23
#3 0x282edbc0 in gz_reader () from /usr/local/lib/libneon.so.23
#4 0x282e4568 in ne_read_response_block () from /usr/local/lib/libneon.so.23
#5 0x282e5293 in ne_request_dispatch () from /usr/local/lib/libneon.so.23
#6 0x280f371a in svn_ra_dav__request_dispatch (code=0xbfbff4fc,
request=0x8078800, session=0x8066800, method=0x280f402c "GET",
url=0x28028b88
"/repos/svn/!svn/bc/6365/branches/fs-schema-changes/www/project_license.html",
okay_1=200, okay_2=226, pool=0x8079018)
at subversion/libsvn_ra_dav/util.c:454
#7 0x280ed40e in custom_get_request (sess=0x8066800,
url=0x28028b88
"/repos/svn/!svn/bc/6365/branches/fs-schema-changes/www/project_license.html",
relpath=0x0, reader=0x280ed4b0 <fetch_file_reader>,
subctx=0xbfbff570, get_wc_prop=0, cb_baton=0x0, use_base=1,
pool=0x8079018)
at subversion/libsvn_ra_dav/fetch.c:503
#8 0x280ed69d in simple_fetch_file (sess=0x8066800,
url=0x28028b88
"/repos/svn/!svn/bc/6365/branches/fs-schema-changes/www/project_license.html",
relpath=0x0, text_deltas=1, file_baton=0x80790a0,
base_checksum=0x0, editor=0x806d120, get_wc_prop=0, cb_baton=0x0,
pool=0x8079018) at subversion/libsvn_ra_dav/fetch.c:670
#9 0x280ed770 in fetch_file (sess=0x8066800, rsrc=0x28028b10,
dir_baton=0x280188f0, editor=0x806d120,
edit_path=0x81dd330 "branches/fs-schema-changes/www/project_license.html",
pool=0x8079018) at subversion/libsvn_ra_dav/fetch.c:704
#10 0x280ee486 in svn_ra_dav__do_checkout (session_baton=0x806d288,
revision=-1, recurse=1, editor=0x806d120, edit_baton=0x806d158,
pool=0x806d018) at subversion/libsvn_ra_dav/fetch.c:1305
#11 0x2807b9e6 in svn_client__checkout_internal (
URL=0x8060c18 "http://svn.collab.net/repos/svn", path=0x8060c78 "svn",
revision=0xbfbff914, recurse=1, timestamp_sleep=0x0, ctx=0xbfbff8ec,
pool=0x806d018) at subversion/libsvn_client/checkout.c:112
#12 0x2807ba6b in svn_client_checkout (
URL=0x8060c18 "http://svn.collab.net/repos/svn", path=0x8060c78 "svn",
revision=0xbfbff914, recurse=1, ctx=0xbfbff8ec, pool=0x806d018)
at subversion/libsvn_client/checkout.c:151
#13 0x804b2d6 in svn_cl__checkout (os=0x8060050, baton=0xbfbff7a0,
pool=0x8060018) at subversion/clients/cmdline/checkout-cmd.c:133
#14 0x804dc30 in main (argc=3, argv=0xbfbff9f0)
at subversion/clients/cmdline/main.c:1026
#15 0x804ae6a in _start ()
Running "svn --version" yields:
svn, version 0.23.0 (r5962)
compiled Jun 12 2003, 11:01:26
Copyright (C) 2000-2003 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
The following repository access (RA) modules are available:
* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' schema
- handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
- handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' schema
I'm running FreeBSD 4.8 on ia32 (more specifically, an Athlon);
this version of Subversion was built from the port in a recent
FreeBSD ports tree. Anything further I should do? Or is this
not interesting on account of being with an old version of Subversion?
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.
My libneon wasn't built with debugging turned on, but apparently
Subversion was. "info locals" in frame #6 says:
error_parser = (ne_xml_parser *) 0x80a8000
rv = 672088108
msg = 0x0
err = (svn_error_t *) 0x0
which may or may not be useful.
--
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 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
Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)
Posted by Joe Orton <jo...@redhat.com>.
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 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?
--
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 Joe Orton <jo...@redhat.com>.
On Sat, Jun 28, 2003 at 04:12:47AM -0500, Mike Pilato wrote:
> Gareth McCaughan <ga...@pobox.com> writes:
>
> > #0 0x284b77f8 in vfprintf () from /usr/lib/libc.so.4
> > (gdb) backtrace
> > #0 0x284b77f8 in vfprintf () from /usr/lib/libc.so.4
> > #1 0x28481e24 in vsnprintf () from /usr/lib/libc.so.4
> > #2 0x282e5a81 in ne_set_error () from /usr/local/lib/libneon.so.23
> > #3 0x282edbc0 in gz_reader () from /usr/local/lib/libneon.so.23
> > #4 0x282e4568 in ne_read_response_block () from /usr/local/lib/libneon.so.23
> > #5 0x282e5293 in ne_request_dispatch () from /usr/local/lib/libneon.so.23
> > #6 0x280f371a in svn_ra_dav__request_dispatch (code=0xbfbff4fc,
> > request=0x8078800, session=0x8066800, method=0x280f402c "GET",
> > url=0x28028b88
> > "/repos/svn/!svn/bc/6365/branches/fs-schema-changes/www/project_license.html",
> > okay_1=200, okay_2=226, pool=0x8079018)
> > at subversion/libsvn_ra_dav/util.c:454
>
> [...]
>
> > 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.
> > My libneon wasn't built with debugging turned on, but apparently
> > Subversion was. "info locals" in frame #6 says:
> >
> > error_parser = (ne_xml_parser *) 0x80a8000
> > rv = 672088108
> > msg = 0x0
> > err = (svn_error_t *) 0x0
>
> This all looks fine. rv is set when svn_ra_dav__request_dispatch()
> returns (and isn't initialized previously). The other vars are fine,
> too.
>
> ne_set_error() is used all over the Neon library in exactly the same
> way. The only one in your stack that at a glance I can't feel
> comfortable about is here:
... the inflateInit2 call...
> Other neon code does stuff like:
>
> ctx->zstr.msg?ctx->zstr.msg:"(no message)"
>
> to make sure that it isn't dereferencing a NULL pointer. Perhaps this
> code should be doing the same thing, and perhaps the fact that it
> isn't is what has caused your segfault.
>
> Joe Orton: thoughts?
Yes, you're right that this use of .msg should be protected against NULL
pointers too, the zlib inflateInit documentation says this can happen.
I'll add a check to neon; thanks for tracking this down.
Regards,
joe
---------------------------------------------------------------------
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 cm...@collab.net.
Gareth McCaughan <ga...@pobox.com> writes:
> #0 0x284b77f8 in vfprintf () from /usr/lib/libc.so.4
> (gdb) backtrace
> #0 0x284b77f8 in vfprintf () from /usr/lib/libc.so.4
> #1 0x28481e24 in vsnprintf () from /usr/lib/libc.so.4
> #2 0x282e5a81 in ne_set_error () from /usr/local/lib/libneon.so.23
> #3 0x282edbc0 in gz_reader () from /usr/local/lib/libneon.so.23
> #4 0x282e4568 in ne_read_response_block () from /usr/local/lib/libneon.so.23
> #5 0x282e5293 in ne_request_dispatch () from /usr/local/lib/libneon.so.23
> #6 0x280f371a in svn_ra_dav__request_dispatch (code=0xbfbff4fc,
> request=0x8078800, session=0x8066800, method=0x280f402c "GET",
> url=0x28028b88
> "/repos/svn/!svn/bc/6365/branches/fs-schema-changes/www/project_license.html",
> okay_1=200, okay_2=226, pool=0x8079018)
> at subversion/libsvn_ra_dav/util.c:454
[...]
> 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.
>
> My libneon wasn't built with debugging turned on, but apparently
> Subversion was. "info locals" in frame #6 says:
>
> error_parser = (ne_xml_parser *) 0x80a8000
> rv = 672088108
> msg = 0x0
> err = (svn_error_t *) 0x0
This all looks fine. rv is set when svn_ra_dav__request_dispatch()
returns (and isn't initialized previously). The other vars are fine,
too.
ne_set_error() is used all over the Neon library in exactly the same
way. The only one in your stack that at a glance I can't feel
comfortable about is here:
In ne_compress.c:gz_reader()
[...]
case NE_Z_BEFORE_DATA:
/* work out whether this is a compressed response or not. */
if (ctx->enchdr && strcasecmp(ctx->enchdr, "gzip") == 0) {
NE_DEBUG(NE_DBG_HTTP, "compress: got gzipped stream.\n");
/* This is the magic bit: using plain inflateInit()
* doesn't work, and this does, but I have no idea why..
* Google showed me the way. */
if (inflateInit2(&ctx->zstr, -MAX_WBITS) != Z_OK) {
ne_set_error(ctx->session, ctx->zstr.msg);
ctx->state = NE_Z_ERROR;
return;
}
ctx->zstrinit = 1;
[...]
Other neon code does stuff like:
ctx->zstr.msg?ctx->zstr.msg:"(no message)"
to make sure that it isn't dereferencing a NULL pointer. Perhaps this
code should be doing the same thing, and perhaps the fact that it
isn't is what has caused your segfault.
Joe Orton: thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org