Re: segfault after merge

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.

--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