[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: Sat, 2 Feb 2008 07:50:48 +0100

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?

HTH,

Erik.

> --dave
>
>
> On Feb 1, 2008 6:05 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > The specific place where the segv is happening appears to be an
> > attempt to "unhook" a ne_compress's hook (in neon-land) from its
> > enclosing Neon session. After r28442, this session gets deleted
> > earlier than the "unhook" gets called. That is, somehow the
> > ne_compress is getting deleted far too late (during global cleanup, it
> > looks like), by which time the Neon session itself has long been
> > freed. Or something.
> >
> > --dave
> >
> >
> > On Feb 1, 2008 6:00 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > > This was caused by the sesspools in r28442. Dunno how.
> > >
> > > --dave
> > >
> > >
> > > On Feb 1, 2008 3:31 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > > > On a Mac, using Neon.
> > > >
> > > > Check out trunk @ 29154.
> > > >
> > > > Build and install it.
> > > >
> > > > filthy-assistant:~/Projects/Subversion/svn-trunk glasser$ svn merge
> > > > -c-29139 http://svn.collab.net/repos/svn/trunk
> > > > --- Reverse-merging r29139 into '.':
> > > > U subversion/libsvn_fs_base/fs.c
> > > > U subversion/svnadmin/main.c
> > > > U subversion/include/svn_error_codes.h
> > > > U subversion/include/svn_fs.h
> > > > U subversion/include/svn_repos.h
> > > > U subversion/libsvn_fs/fs-loader.h
> > > > U subversion/libsvn_fs/fs-loader.c
> > > > U subversion/libsvn_repos/repos.c
> > > > U subversion/libsvn_fs_fs/fs_fs.c
> > > > U subversion/libsvn_fs_fs/fs_fs.h
> > > > U subversion/libsvn_fs_fs/fs.c
> > > > Segmentation fault
> > > >
> > > > Wee! Reproducible.
> > > >
> > > > Your friend and mine, gdb, sez:
> > > >
> > > > #0 0x007dd67b in remove_hook ()
> > > > #1 0x007e5112 in ne_decompress_destroy ()
> > > > #2 0x005caa64 in compressed_body_reader_cleanup (baton=0x1890e00) at
> > > > subversion/libsvn_ra_neon/util.c:391
> > > > #3 0x010fb8b1 in run_cleanups (cref=0x188c228) at memory/unix/apr_pools.c:2082
> > > > #4 0x010fc22d in apr_pool_destroy (pool=0x188c218) at
> > > > memory/unix/apr_pools.c:753
> > > > #5 0x010fc218 in apr_pool_destroy (pool=0x180b418) at
> > > > memory/unix/apr_pools.c:750
> > > > #6 0x0000d84d in main (argc=4, argv=0xbfffd0c8) at subversion/svn/main.c:1998
> > > >
> > > > so really that just means "we corrupted some memory, somewhere".
> > > >
> > > > --dave
> > > >
> > > > --
> > > > David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
> > > >
> > >
> > >
> > >
> > > --
> > > David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
> > >
> >
> >
> >
> > --
> >
> > David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
> >
>
>
>
> --
> 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-02 07:51:13 CET

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.