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

Re: Segfault in "svn checkout" (svn client 0.23; server at collab.net)

From: Joe Orton <jorton_at_redhat.com>
Date: 2003-06-30 11:49:15 CEST

On Sat, Jun 28, 2003 at 04:12:47AM -0500, Mike Pilato wrote:
> Gareth McCaughan <gareth.mccaughan@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
Received on Mon Jun 30 11:50:08 2003

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.