Re: [PATCH] git-svn: write memoized data explicitly to avoid Storable bug

From: Eric Wong <normalperson@yhbt.net>
Date: Jul 20, 2010, 19:02 UTC
Message-ID: <20100720190223.GB2732@dcvr.yhbt.net>
In-Reply-To: <AANLkTime7QQZGLXmXg_X3W7CsbyLe5NbPKcqs9dp0oaa@mail.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 28 quoted lines

> On Sun, Jul 18, 2010 at 12:17, Sergey Vlasov <vsu@altlinux.ru> wrote:
> > Apparently using the Storable module during global destruction is
> > unsafe - there is a bug which can cause segmentation faults:
> >
> >  http://rt.cpan.org/Public/Bug/Display.html?id=36087
> >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482355
> 
> I did some investigation into the upstream issue:
> https://rt.cpan.org/Ticket/Display.html?id=36087#txn-806832
> 
> > The persistent memoization support introduced in commit 8bff7c538
> > relied on global destruction to write cached data, which was leading
> > to segfaults in some Perl configurations.  Calling Memoize::unmemoize
> > in the END block forces the cache writeout to be performed earlier,
> > thus avoiding the bug.
> 
> Maybe I'm missing something obvious, but this seems like the wrong
> solution. The core issue is that we don't want to clean up during
> global destruction, but then we should just do:
> 
>        sub DESTROY {
>                return if not $memoized;
>                $memoized = 0;
> 
>                Memoize::unmemoize 'lookup_svn_merge';
>                Memoize::unmemoize 'check_cherry_pick';
>                Memoize::unmemoize 'has_no_changes';
>        }

I haven't looked at this issue in-depth, but I believe the problem is triggered due to Memoize::Storable trying to use Storable::nstore in its own DESTROY function. So trying to do the same in our own DESTROY would be just as bad.

> That should work since memoize_svn_mergeinfo_functions(); is being
> called in find_extra_svn_parents, which is a Git::SVN object
> method. Can you try this and confirm/deny? I can't because I can't get
> the original to segfault on my box when run within git-svn.

I wasn't able to reproduce the segfault on my systems, either, but it seems plausible it would only happen on some systems.

-- 
Eric Wong