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?
--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 03:12:56 CET