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.
bye,
Erik.
---------------------------------------------------------------------
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 08:41:53 CET