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

Re: segfault after merge

From: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 8 Feb 2008 00:06:23 -0800

On Feb 7, 2008 11:41 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
>
> On Feb 8, 2008 2:01 AM, David Glasser <glasser_at_davidglasser.net> wrote:
> >
> > On Feb 7, 2008 4:14 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > >
> > > On Feb 7, 2008 12:40 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > > > On Feb 2, 2008 2:15 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> > > > > On Feb 2, 2008 8:51 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > > > > > On Feb 1, 2008 10:50 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> > > > > > > On Feb 2, 2008 3:12 AM, David Glasser <glasser_at_davidglasser.net> wrote:
> > > > > > > > Erik, I'm thinking the underlying problem here relates to
> > > > > > > > r22374/r22845. Specifically, the destructor for the ne_uncompress is
> > > > > > > > called on the cleanup of the request's pool, but AFAICT there's
> > > > > > > > nothing preventing that pool from outliving the session itself. So
> > > > > > > > you can call the ne_uncompress destructor after the session is gone,
> > > > > > > > and BOOM. Can you look into this?
> > > > > > >
> > > > > > > My only reaction is "don't do that": Neon depends on the session to
> > > > > > > exist when destroying requests. I'd say it shouldn't be impossible for
> > > > > > > us to make sure we destroy our requests before we destroy the
> > > > > > > sessions. I fixed an instance of this before. Maybe that's also
> > > > > > > possible in this case?
> > > > > >
> > > > > > Do you know where the instance you fixed before was?
> > > > > >
> > > > > > I guess we just need to find the request in question and run it in a subpool.
> > > > >
> > > > > Other than it being in libsvn_client? Not really anymore. But if you
> > > > > have a reproduction recipe with the svn repository, maybe I'll be able
> > > > > to use gdb to find out?
> > > >
> > > > For the record, I'm still seeing this segfault, so Mike's
> > > > repos-root/uuid changes (while a good idea) didn't help here.
> > > > Hopefully I can track it down this afternoon.
> > >
> > > I believe r29230 fixes this. I will document
> > > svn_ra_neon__parsed_request as requiring an appropriately short-lived
> > > pool.
> >
> > Instead of making that documentation change, r29231 makes sure that it
> > always destroys its request even on error, which was the specific
> > issue here. Perhaps other parts of the library which create and
> > destroy requests need to have similar changes.
>
> I think nearly all or even all requests are routed through
> svn_ra_neon__parsed_request() these days. I expect problems to be
> solved now.

I fixed the handful of other requests in r29233.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-08 09:06:34 CET

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